freebsd-hackers-digest V5 #748

[owner-freebsd-...@freebsd.org]

freebsd-hackers-digest Tuesday, March 18 2003 Volume 05 : Number 748

In this issue:
Re: making CVS more convenient
Re: making CVS more convenient
Re: making CVS more convenient
Re: making CVS more convenient
Re: making CVS more convenient
Re: making CVS more convenient
section of source code handling reclamation of KVM
NFS performance tuning
Re: making CVS more convenient
Re: NFS performance tuning
Мечта юнного человека!!!
some questions about ACL implementation
Re: debugging a repeating panic (solved)
HP-UX FS mountable?
Re: some questions about ACL implementation
pmap_wired_count() macro?
Re: NFS performance tuning
Re: fgdg
High CPU usage on high-bandwidth long distance connections.
Re: High CPU usage on high-bandwidth long distance connections.
rumour of password aging failure in 4.7/4.8RC
Re: HP-UX FS mountable?
Sound drivers
Re: rumour of password aging failure in 4.7/4.8RC
Re: ether_input: drop bdg packet
Re: rumour of password aging failure in 4.7/4.8RC
Re: rumour of password aging failure in 4.7/4.8RC

----------------------------------------------------------------------

Date: Mon, 17 Mar 2003 17:20:44 -0500
From: Sergey Babkin <bab...@bellatlantic.net>
Subject: Re: making CVS more convenient

Nate Williams wrote:
>
> > That's the plan for the next stage, provided that the first stage
> > goes well. I'm yet to play with CVSup and see if it can be
> > integrated there (as with system()) easily without making a lot
> > of changes to CVS itself. Otherwise I'm aftarid it's going to
> > be a large amount of work to duplicate this functionality :-(
>
> Another choice is to have the commit be also made to the 'cache' if and
> only if the remote (master) respository has accepted the commit.
>
> That way, the commit is made in both repositories using the same
> algorithm, so in essence they should be in sync.

Yes, makes sense.

> > Yet another idea is to be able to make "local commits" with committing
> > them to the central remote repository later.
>
> I'd do the reverse, since the possibility of synchronization problems
> are a huge deal. Imagine if someone 'snuck' in and made a commit in
> the master tree after your local commit was made, but before 'later'
> occurred and your cache pushed it out to the master tree.

It gets handled in the same way as now: I believe, CVS checks
whether the checked-out version matches the top of the branch,
and if it does not then it refuses to commit and requires you
to make an update. So the same thing can be done for a "local branch":
check that its base version is still the top of the real branch,
and if so then commit. Otherwise require an update/merge.

> If you only allow the commit if it can occur locally, you're ensuring
> that the cache can't get out of date with local changes. I tried
> something like the above (cause it was easier to implement), and it
> worked most of the time. However, the times it didn't work it was a
> royal pain in the *ss to cleanup and get the original commit back out.

Maybe I just was not clear: I think that making the commits in the
local copy on the real top of the tree is a quite bad idea. All
I want to get is some temporary versioned storage to play around
while I work on the code. After the code gets finished, it
gets committed to the master repository just as it committed gets now.

> > Now I have to use RCS
> > locally for the temporary in-delevopment versions of file. Would
> > be nice to have a kind of a local branch which can be later committed
> > as a whole - in one commit per file, or by duplicating all the
> > intermediate versions with their messages.
>
> Agreed. The downside to the above method is that it requires network
> access to make a commit. However, it certainly simplifies the
> problem set. :) :)

Well, at least the commit would get done in one batch (of course,
unless a conflict happens).

- -SB

------------------------------

Date: Mon, 17 Mar 2003 15:28:06 -0700
From: Nate Williams <na...@yogotech.com>
Subject: Re: making CVS more convenient

> > > That's the plan for the next stage, provided that the first stage
> > > goes well. I'm yet to play with CVSup and see if it can be
> > > integrated there (as with system()) easily without making a lot
> > > of changes to CVS itself. Otherwise I'm aftarid it's going to
> > > be a large amount of work to duplicate this functionality :-(
> >
> > Another choice is to have the commit be also made to the 'cache' if and
> > only if the remote (master) respository has accepted the commit.
> >
> > That way, the commit is made in both repositories using the same
> > algorithm, so in essence they should be in sync.
>
> Yes, makes sense.
>
> > > Yet another idea is to be able to make "local commits" with committing
> > > them to the central remote repository later.
> >
> > I'd do the reverse, since the possibility of synchronization problems
> > are a huge deal. Imagine if someone 'snuck' in and made a commit in
> > the master tree after your local commit was made, but before 'later'
> > occurred and your cache pushed it out to the master tree.
>
> It gets handled in the same way as now: I believe, CVS checks
> whether the checked-out version matches the top of the branch,
> and if it does not then it refuses to commit and requires you
> to make an update. So the same thing can be done for a "local branch":
> check that its base version is still the top of the real branch,
> and if so then commit. Otherwise require an update/merge.

Except that it's possible that the 'local' cache is out-of-date
w/respect to the remote repository, say if someone made a commit to it
since the last 'synchronization' of the local cache.

You don't want that commit to happen, since it should be allowed because
the file is really not up-to-date w/respect to the master. The worst
case is the committed change would conflict with the as-yet-unseen
change on the master, so allowing the local user to commit it means that
when the 'cache' attempts to commit it later, it will fail, and the
'cache code' is required to figure out how to extract the commit from
the local cache, update the local cache, re-apply the (now conflicing)
commit back to the local cache and somehow inform the user at a later
point.

*UGH*

> > If you only allow the commit if it can occur locally, you're ensuring
> > that the cache can't get out of date with local changes. I tried
> > something like the above (cause it was easier to implement), and it
> > worked most of the time. However, the times it didn't work it was a
> > royal pain in the *ss to cleanup and get the original commit back out.
>
> Maybe I just was not clear: I think that making the commits in the
> local copy on the real top of the tree is a quite bad idea.

I think it's a good idea *IF and only IF* the commit to the remote tree
works. That way, the local user isn't required to re-synchronize his
cached tree agains the master tree, since their is a high liklihood that
after the commit the user will also want to continue working on the same
files. If no re-sychronization occurs, as soon as an 'cvs update' is
done, the local cache must either re-synchronize itself (doing the exact
same work as if it just done the commit), or the newly committed change
will be reverted back out, since the local cache will now be
out-of-date.

> I want to get is some temporary versioned storage to play around
> while I work on the code. After the code gets finished, it
> gets committed to the master repository just as it committed gets now.

What happens to the local cache *right after* the commit occurs? In
essence, it's no longer valid right after a commit, since it's now
out-of-date with the master (it doesn't include the newly committed
changes).

> > > Now I have to use RCS
> > > locally for the temporary in-delevopment versions of file. Would
> > > be nice to have a kind of a local branch which can be later committed
> > > as a whole - in one commit per file, or by duplicating all the
> > > intermediate versions with their messages.
> >
> > Agreed. The downside to the above method is that it requires network
> > access to make a commit. However, it certainly simplifies the
> > problem set. :) :)
>
> Well, at least the commit would get done in one batch (of course,
> unless a conflict happens).

Right, it's a step in the right direction.

Nate

------------------------------

Date: Mon, 17 Mar 2003 17:34:06 -0500
From: Sergey Babkin <bab...@bellatlantic.net>
Subject: Re: making CVS more convenient

Dag-Erling Smшrgrav wrote:
>
> Sergey Babkin <bab...@bellatlantic.net> writes:
> > A similar thing may be achieved by checking the files out from the local
> > repository and doing any modification command with option -d. But that's
> > troublesome and inconvenient.
>
> Read the manual page for the shell you're using, with particular
> emphasis on the 'alias' builtin command.

I think that it's not a good solution, for several reasons:

* Using -d for an alternative repository is pretty much a dirty
trick, and undocumented one too. But the purpose itself is quite
valid, transparent, and simple and I think that it's better to make
it obvious and easy to use than tricky. I like the principle
"simple things should be easy, complex things should be possible".

* There may be scripts that run cvs commands, which scripts absolutely
don't need to know about a cache repository underneath.

* I don't like the layers of "workaround scripts" built over other
"workaround scripts". I think that it's something of an "aftermarket
Unix syndrome": when you can trick a tool to do what you want and
wrap it into a script for the ease of use but can't change the tool
to do what you need directly, in a simple way. The original Unix
(both Bell Labs and BSD) was not like this: when the people made
some useful addition, they just got it right into the base system.
Now with open source OSes we can do the same thing and not look
for extra pain with wrapper scripts.

* Getting the cache repository support right into CVS allows
to modify the CVS commands in future to take advantage of this
knowledge. For example, "commit" may not just check the
modification date and send the file to the server if it has changed,
but instead also compare the file with the one in the cache
repository and send it to the server only if the file has actually
changed.

- -SB

------------------------------

Date: Mon, 17 Mar 2003 17:59:37 -0500
From: Sergey Babkin <bab...@bellatlantic.net>
Subject: Re: making CVS more convenient

Terry Lambert wrote:
>
> Sergey Babkin wrote:
> > Nate Williams wrote:
>
> [ ... "CVS cache and cache coherency" ... ]
>
> > Yet another idea is to be able to make "local commits" with committing
> > them to the central remote repository later. Now I have to use RCS
> > locally for the temporary in-delevopment versions of file. Would
> > be nice to have a kind of a local branch which can be later committed
> > as a whole - in one commit per file, or by duplicating all the
> > intermediate versions with their messages.
>
> Not really possible, without CVSup coming onto a vendor branch instead

Actually, I was thinking of the opposite: doing all the changes
on a vendor branch (or in some separate local repository altogether),
then merging them into the main branch. Think of the following
sequence that can be used now:

cvs co
rcs ci # save the baseline
#... some modifications done
rcs ci
#... more modifications
rcs ci
# then someone committed another change to the repository and we want
# to merge that change in
cvs update
# do the manual merge if neccessary
rcs ci # save the merged version
#... more modifications
rcs ci
# OK, let's suppose that our changes are finally complete, and nobody
# else has committed any other changes in between
cvs ci

So pretty much all I want is to make this procedure a bit more
convenient, able to handle whole subdirectories as opposed
to separate files.

As a model consider this: suppose we build a separate copy of the CVS
binary, called "mycvs" that has the following differences from
the normal CVS:

1. Instead of the variable CVSROOT it uses MYCVSROOT
2. Instead of the metadata subdirectory name CVS it uses the name MYCVS
3. It never touches any of the keywords (such as $Id etc.)
4. When asked to add a file, it automatically creates the whole
path of intermediate directories for it. (How does it know where
the checked-out tree starts ? There are many more or less
obvious and convenient ways to do that, so let's leave this issue
alone for now).

Then in the example above you can do

export MYCVSROOT=~/tmp/cvsroot
mycvs init

And do everyhing as in the previous example, only replacing rcs
with mycvs (and obviously you wold need to do "mycvs add" before
the fiest "mycvs ci").

> of verbatim copying of the repository.
>
> Incoherent:
>
> ,-------. ,-------.
> | Main |---- cvsup --->| Cache |
> | Repo | | Repo |
> `-------' `-------'
> ^ |
> | cvs co
> cvs ci |
> | V
> | ,-------.
> | | Work |
> `-------------------| Copy |
> `-------'

Why is it incoherent ? CVS checks that the version obtained by "cvs co"
and then modified is still the top of the tree. If it's not,
it will refuse to commit and will request you to do an update.

- -SB

------------------------------

Date: Mon, 17 Mar 2003 18:18:01 -0500
From: Sergey Babkin <bab...@bellatlantic.net>
Subject: Re: making CVS more convenient

Nate Williams wrote:
>
> > It gets handled in the same way as now: I believe, CVS checks
> > whether the checked-out version matches the top of the branch,
> > and if it does not then it refuses to commit and requires you
> > to make an update. So the same thing can be done for a "local branch":
> > check that its base version is still the top of the real branch,
> > and if so then commit. Otherwise require an update/merge.
>
> Except that it's possible that the 'local' cache is out-of-date
> w/respect to the remote repository, say if someone made a commit to it
> since the last 'synchronization' of the local cache.
>
> You don't want that commit to happen, since it should be allowed because
> the file is really not up-to-date w/respect to the master. The worst
> case is the committed change would conflict with the as-yet-unseen
> change on the master, so allowing the local user to commit it means that
> when the 'cache' attempts to commit it later, it will fail, and the
> 'cache code' is required to figure out how to extract the commit from
> the local cache, update the local cache, re-apply the (now conflicing)
> commit back to the local cache and somehow inform the user at a later
> point.
>
> *UGH*

Yes, this is way too complicated and error-prone. This is why I don't
want to change the cache without changing the master in the same way
first.

> > > If you only allow the commit if it can occur locally, you're ensuring
> > > that the cache can't get out of date with local changes. I tried
> > > something like the above (cause it was easier to implement), and it
> > > worked most of the time. However, the times it didn't work it was a
> > > royal pain in the *ss to cleanup and get the original commit back out.
> >
> > Maybe I just was not clear: I think that making the commits in the
> > local copy on the real top of the tree is a quite bad idea.
>
> I think it's a good idea *IF and only IF* the commit to the remote tree
> works. That way, the local user isn't required to re-synchronize his
> cached tree agains the master tree, since their is a high liklihood that

Agreed. So the commit would essentially work as a commit plus
resynchronization of a subset of files in the cache.

- -SB

------------------------------

Date: Mon, 17 Mar 2003 16:20:53 -0700
From: Nate Williams <na...@yogotech.com>
Subject: Re: making CVS more convenient

> > > It gets handled in the same way as now: I believe, CVS checks
> > > whether the checked-out version matches the top of the branch,
> > > and if it does not then it refuses to commit and requires you
> > > to make an update. So the same thing can be done for a "local branch":
> > > check that its base version is still the top of the real branch,
> > > and if so then commit. Otherwise require an update/merge.
> >
> > Except that it's possible that the 'local' cache is out-of-date
> > w/respect to the remote repository, say if someone made a commit to it
> > since the last 'synchronization' of the local cache.
> >
> > You don't want that commit to happen, since it should be allowed because
> > the file is really not up-to-date w/respect to the master. The worst
> > case is the committed change would conflict with the as-yet-unseen
> > change on the master, so allowing the local user to commit it means that
> > when the 'cache' attempts to commit it later, it will fail, and the
> > 'cache code' is required to figure out how to extract the commit from
> > the local cache, update the local cache, re-apply the (now conflicing)
> > commit back to the local cache and somehow inform the user at a later
> > point.
> >
> > *UGH*
>
> Yes, this is way too complicated and error-prone. This is why I don't
> want to change the cache without changing the master in the same way
> first.

I think we're in *violent* agreement at this point. :)

> > > > If you only allow the commit if it can occur locally, you're ensuring
> > > > that the cache can't get out of date with local changes. I tried
> > > > something like the above (cause it was easier to implement), and it
> > > > worked most of the time. However, the times it didn't work it was a
> > > > royal pain in the *ss to cleanup and get the original commit back out.
> > >
> > > Maybe I just was not clear: I think that making the commits in the
> > > local copy on the real top of the tree is a quite bad idea.
> >
> > I think it's a good idea *IF and only IF* the commit to the remote tree
> > works. That way, the local user isn't required to re-synchronize his
> > cached tree agains the master tree, since their is a high liklihood that
>
> Agreed. So the commit would essentially work as a commit plus
> resynchronization of a subset of files in the cache.

*grin* I love it when a plan comes together.

Nate

------------------------------

Date: Mon, 17 Mar 2003 17:24:51 -0800
From: "Andrew Kinney" <andyk...@advantagecom.net>
Subject: section of source code handling reclamation of KVM

Hello,

I'd like to learn more about how FreeBSD handles running out of
KVM. We're running a 4GB of RAM system with no swap being
used, but we're run out of KVM and I'd like to go read through the
code to see how this is handled so I can be on the lookout for
potential issues that may come up.

%sysctl -a |grep kvm
vm.kvm_size: 1065353216
vm.kvm_free: 0

Could someone direct me to the section of the 4.7 source tree that
handles additional KVM requests when vm.kvm_free=0 so I can go
read up on the process?

Thanks in advance.

Sincerely,
Andrew Kinney
President and
Chief Technology Officer
Advantagecom Networks, Inc.
http://www.advantagecom.net

------------------------------

Date: Mon, 17 Mar 2003 21:02:01 -0500
From: John <j...@bsdwins.com>
Subject: NFS performance tuning

Hi Folks,

This is an open ended email with a question about how
to increase performance of a 4-stable system running in a
high-load environment. The src is current as of:

FreeBSD 4.8-RC #1: Sun Mar 16 15:44:01

Running top on the system:

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
93 root 2 0 360K 148K RUN 197:27 48.49% 48.49% nfsd
94 root 2 0 360K 148K RUN 28:36 5.71% 5.71% nfsd
96 root 2 0 360K 148K RUN 10:37 3.66% 3.66% nfsd
95 root 2 0 360K 148K RUN 18:34 3.27% 3.27% nfsd
98 root 2 0 360K 148K RUN 6:25 1.03% 1.03% nfsd
97 root 2 0 360K 148K RUN 8:17 0.83% 0.83% nfsd
3201 admin 30 0 1908K 1056K RUN 0:00 1.19% 0.73% top
99 root 2 0 360K 148K RUN 5:21 0.63% 0.63% nfsd
101 root 2 0 360K 148K RUN 4:18 0.20% 0.20% nfsd

and a ps a minute or so later:

PID PPID UID %CPU %MEM STAT TIME COMMAND
92 1 0 0.0 0.0 Is 0:00.00 nfsd: master (nfsd)
93 92 0 45.3 0.0 R 199:46.61 nfsd: server (nfsd)
94 92 0 5.0 0.0 R 28:57.60 nfsd: server (nfsd)
95 92 0 2.1 0.0 R 18:48.99 nfsd: server (nfsd)
96 92 0 1.1 0.0 R 10:45.36 nfsd: server (nfsd)
97 92 0 0.3 0.0 R 8:23.25 nfsd: server (nfsd)
98 92 0 0.4 0.0 R 6:30.47 nfsd: server (nfsd)
99 92 0 0.2 0.0 R 5:25.05 nfsd: server (nfsd)
101 92 0 0.2 0.0 R 4:21.38 nfsd: server (nfsd)

The nfsd processes are almost always Runnable.

The box is an athlon MP 2200+ based system on a tyan
S2466 motherboard (http://www.tyan.com/products/html/tigermpx.html)
with only one processor currently installed, 2Gig of Ram.

The filesystem being served out lives on an Adaptec 5400S Raid controller:

aac0: <Adaptec SCSI RAID 5400S> port 0x1000-0x10ff mem 0xe8000000-0xe8001fff irq 9 at device 9.0 on pci0
aac0: StrongARM SA110 233MHz, 128MB cache memory, required battery present
aac0: Kernel 1.0-0, Build 5262, S/N 6b1830

aacd1: <RAID 5> on aac0
aacd1: 769984MB (1576929024 sectors)

The system is located on 5 different networks: (netstat -i)

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
gx0 1500 <Link#1> 00:90:27:a1:5d:0b 12056041 0 14715548 0 0
gx0 1500 192.168.30 192.168.30.250 12055944 - 14715450 - -
gx1 1500 <Link#2> 00:90:27:a1:44:5a 2269975 0 2753705 0 0
gx1 1500 192.168.31 192.168.31.250 2269878 - 2753607 - -
fxp0 1500 <Link#3> 00:02:b3:60:b5:3a 241440300 0 246915204 946 0
fxp0 1500 10.14.2/24 bb03na1a.hsr.sa 241447878 - 246924642 - -
fxp1 1500 <Link#4> 00:02:b3:4a:76:e6 117933878 706 122043638 921 0
fxp1 1500 10.14.3/24 bb03na1b.hsr.sa 117939587 - 122051034 - -
fxp2 1500 <Link#5> 00:02:b3:60:a8:9d 303742731 0 310860180 901 0
fxp2 1500 10.14.4/24 bb03na1c.hsr.sa 303760088 - 310879510 - -

(The gx cards are 1000baseSX <full-duplex>).
(The fxp cards are 100baseTX <full-duplex>).

and from netstat -m:

%netstat -m
916/2512/34816 mbufs in use (current/peak/max):
894 mbufs allocated to data
22 mbufs allocated to packet headers
729/1160/8704 mbuf clusters in use (current/peak/max)
2948 Kbytes allocated to network (11% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

and from nfsstat:

Server Info:
Getattr Setattr Lookup Readlink Read Write Create Remove
31122 62636 600335411 186827 5952269 815008 90198 59781
Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access
22236 0 15 8067 15989 198862 48 78463316
Mknod Fsstat Fsinfo PathConf Commit GLease Vacate Evict
0 242190 8 0 149734 0 0 0
Server Ret-Failed
591695228
Server Faults
0
Server Cache Stats:
Inprog Idem Non-idem Misses
228 11658 52 686794492
Server Lease Stats:
Leases PeakL GLeases
0 0 0
Server Write Gathering:
WriteOps WriteRPC Opsaved
815008 815008 0

The system holds alot of c and h files along with other
pretty static data. The performance of the system is not
bad, but I'm curious about what folks might do to tune it
up some.

Anyways, comments welcome!

- -john

------------------------------

Date: Mon, 17 Mar 2003 20:12:58 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: making CVS more convenient

Sergey Babkin wrote:
> Terry Lambert wrote:
> > Not really possible, without CVSup coming onto a vendor branch instead
>
> Actually, I was thinking of the opposite: doing all the changes
> on a vendor branch (or in some separate local repository altogether),
> then merging them into the main branch. Think of the following
> sequence that can be used now:

[ ... ]

> # OK, let's suppose that our changes are finally complete, and nobody
> # else has committed any other changes in between
> cvs ci

Suppose someone has? If you are so out of touch with the net you
need a cache, you are probably going to get a conflict, because
people are tweaking things all the time, sometimes, it seems,
rearranging the deck chairs to get their name in CVS lights. 8-).

> So pretty much all I want is to make this procedure a bit more
> convenient, able to handle whole subdirectories as opposed
> to separate files.

That's reasonable, but... you're rcs ci is a killer; it assumes
a local repostory in parallel. I guess you want a "multicvs",
which does checkins remotely or locally?

If you want all of your checkins checked in, then you could do
this with a shell script wrapper that knew about "link up" on
your network interfaces. Is that a possible solution for you?

> As a model consider this: suppose we build a separate copy of the CVS
> binary, called "mycvs" that has the following differences from
> the normal CVS:
>
> 1. Instead of the variable CVSROOT it uses MYCVSROOT
> 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS
> 3. It never touches any of the keywords (such as $Id etc.)
> 4. When asked to add a file, it automatically creates the whole
> path of intermediate directories for it. (How does it know where
> the checked-out tree starts ? There are many more or less
> obvious and convenient ways to do that, so let's leave this issue
> alone for now).
>
> Then in the example above you can do
>
> export MYCVSROOT=~/tmp/cvsroot
> mycvs init
>
> And do everyhing as in the previous example, only replacing rcs
> with mycvs (and obviously you wold need to do "mycvs add" before
> the fiest "mycvs ci").

That's actually grosser than the rcs version (IMO)...

> > of verbatim copying of the repository.
> >
> > Incoherent:

[ ... diagram ... ]

> Why is it incoherent ? CVS checks that the version obtained by "cvs co"
> and then modified is still the top of the tree. If it's not,
> it will refuse to commit and will request you to do an update.

I left out the (I thought) obvious part; ket me fix it:

,-------.-----cvsup(1)->,-------.
| Main |---- cvsup(2)->| Cache |<------.
| Repo | [CONFLICT] | Repo | |
`-------' `-------' |
^ | |
| cvs co |
cvs ci(2) | cvs ci(1)
[CONFLICT] V |
cvs ci(3) ,-------. |
| | Work | |
`-------------------| Copy |-------'
`-------'

Order:
cvsup(1)
cvs co
cvs ci(1)
cvs ci(2) [CONFLICT]
[FIX] cvs ci(3)
cvsup(2) [CONFLICT]

In other words, you can't order commits with conflicts, without
going to the main repo first in call cases. That destroys your
intended disconnected use.

The first time you get a conflict, your MYCVSROOT repository
is blown, and you won't be able to resyncronize it, without
replacing ",v" and "CVS/*" file contents.

In other words, any time, there is a "checkin to main repository"
conflict, your foot goes "bye bye"...

Make sense?

- -- Terry

------------------------------

Date: Tue, 18 Mar 2003 08:10:21 +0000
From: David Malone <dwma...@maths.tcd.ie>
Subject: Re: NFS performance tuning

On Mon, Mar 17, 2003 at 09:02:01PM -0500, John wrote:
> This is an open ended email with a question about how
> to increase performance of a 4-stable system running in a
> high-load environment. The src is current as of:

It may be worth chatting to Daniel Ellard, who has some interesting
PRs open on FreeBSD NFS server performance. It certainly sounds like
you could do some testing/benchmarking for him.

David.

------------------------------

Date: Tue, 18 Mar 2003 11:10:09 +0300
From: ok <o...@mail.ru>
Subject: Мечта юнного человека!!!

Здравствуйте!

Мне 13 лет у меня есть мечта !!!! попрошу вас
откликнуться если есть такая возможность.
http://www.zooook.narod.ru

Прошу прощения, если отнял у вас время...
Сергей

------------------------------

Date: Tue, 18 Mar 2003 20:19:15 +0800
From: "ouyang kai" <oy...@msn.com>
Subject: some questions about ACL implementation

Hi, robert
I am reading the ACL implementation based FreeBSD5.0 release. I have some
problems, please help.
1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the
size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so
the sum is 336.
2. what is the relationship of ACL_GROUP_OBJ and ACL_MASK? If I do not
set the ACL EA, we can not get the information of 'ACL_MASK'. ACL_MASK
represents what?
3. "As part of the ACL is stored in the inode, and the rest in an EA,
assemble both into a final ACL product. Right now this is not done very
efficiently.", Do you any viewpoint about that? How we can improve the
efficiency?
4. about ACL based on UFS2, do the ACLs of an inode store di_extb? Could
you introduce the ACLs' management on UFS2?
Thank you very much!
Best Regards
Ouyang Kai

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail

------------------------------

Date: Tue, 18 Mar 2003 08:11:44 -0500
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: debugging a repeating panic (solved)

Just a followup to this, jlemon narrowed down the problem for me to be
inet6 related. He wrote,
- -------------
>I think I narrowed this down to IPv6. In particular, netstat shows:
>
>fe80::%lo0/64 fe80::1%lo0 Uc =
lo0
>fe80::1%lo0 link#3 UHL =
lo0
>
>with the first line being a cloned entry. The route is garbage=20
>collected after 1 day of inactivity, so that's when the crash happens.
>
>I'm not sure why it's crashing just yet, but something seems odd on
>the machine=20

Sure enough, I took out inet6 from the box and no more panics.

Sample dump below. (It was always in the same place)

(kgdb) bt full
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
error =3D 0
#1 0xc016726c in boot (howto=3D256) at =
/usr/src/sys/kern/kern_shutdown.c:316
howto =3D 256
#2 0xc01676ed in panic (fmt=3D0xc03109f9 "%s") at
/usr/src/sys/kern/kern_shutdown.c:595
fmt =3D 0xc03109f9 "%s"
bootopt =3D 256
buf =3D "page fault", '\000' <repeats 245 times>
#3 0xc02bf15e in trap_fatal (frame=3D0xded66e00, eva=3D1089938309) at
/usr/src/sys/i386/i386/trap.c:974
frame =3D (struct trapframe *) 0xded66e00
eva =3D 0
code =3D 16
type =3D 12
ss =3D 16
esp =3D 0
softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D =
27,
ssd_dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 13, ssd_xx1 =3D 2,=20
ssd_def32 =3D 1, ssd_gran =3D 1}
#4 0xc02bedb1 in trap_pfault (frame=3D0xded66e00, usermode=3D0,
eva=3D1089938309) at /usr/src/sys/i386/i386/trap.c:867
va =3D 1089937408
vm =3D (struct vmspace *) 0x0
map =3D 0xdea2a180
rv =3D 0
ftype =3D 1 '\001'
p =3D (struct proc *) 0xded89c60
#5 0xc02be8cb in trap (frame=3D{tf_fs =3D -566231016, tf_es =3D =
- -556269552,
tf_ds =3D -556400624, tf_edi =3D -1020112715,=20
tf_esi =3D -1023322971, tf_ebp =3D -556372388, tf_isp =3D =
- -556372436,
tf_ebx =3D 1089938309, tf_edx =3D -1023322937,=20
tf_ecx =3D -1023322939, tf_eax =3D 28, tf_trapno =3D 12, tf_err =3D=
0, tf_eip
=3D -1072019560, tf_cs =3D 8, tf_eflags =3D 66050,=20
tf_esp =3D 13568, tf_ss =3D -1020112720}) at
/usr/src/sys/i386/i386/trap.c:466
p =3D (struct proc *) 0xded89c60
sticks =3D 15876603469163024560
i =3D 0
ucode =3D 0
type =3D 12
code =3D 0
eva =3D 1089938309
#6 0xc01a4798 in ifa_ifwithnet (addr=3D0xc33250b0) at
/usr/src/sys/net/if.c:611
ifp =3D (struct ifnet *) 0xc035e120
ifa =3D (struct ifaddr *) 0x62000000
ifa_maybe =3D (struct ifaddr *) 0xc3015e00
af =3D 2
addr_data =3D 0xc33250b2 ""
cplim =3D 0x0
#7 0xc01cfa29 in in_pcbladdr (inp=3D0xdc550680, nam=3D0xc33250b0,
plocal_sin=3D0xded66e94) at /usr/src/sys/netinet/in_pcb.c:459
fport =3D 13568
ro =3D (struct route *) 0x3500
plocal_sin =3D (struct sockaddr_in **) 0x0
ia =3D (struct in_ifaddr *) 0x0
sin =3D (struct sockaddr_in *) 0xc33250b0
#8 0xc01cfb17 in in_pcbconnect (inp=3D0xdc550680, nam=3D0xc33250b0,
p=3D0xded89c60) at /usr/src/sys/netinet/in_pcb.c:526
inp =3D (struct inpcb *) 0xdc550680
ifaddr =3D (struct sockaddr_in *) 0xdc550680
sin =3D (struct sockaddr_in *) 0xc33250b0
sa =3D {sin_len =3D 176 '=B0', sin_family =3D 0 '\000', sin_port =
=3D 0,
sin_addr =3D {s_addr =3D 0},=20
sin_zero =3D "\000\000\000\000\200=F41=DC"}
error =3D 0
#9 0xc01e3709 in udp_connect (so=3D0xdc31f480, nam=3D0xc33250b0, =
p=3D0xded89c60)
at /usr/src/sys/netinet/udp_usrreq.c:866
p =3D (struct proc *) 0xded89c60
inp =3D (struct inpcb *) 0xdc550680
s =3D 1644167168
error =3D 0
#10 0xc0186564 in soconnect (so=3D0xdc31f480, nam=3D0xc33250b0, =
p=3D0xded89c60)
at /usr/src/sys/kern/uipc_socket.c:389
so =3D (struct socket *) 0xdc31f480
nam =3D (struct sockaddr *) 0x0
p =3D (struct proc *) 0x0
s =3D 0
error =3D 0
- ---Type <return> to continue, or q <return> to quit---
#11 0xc0189c28 in connect (p=3D0xded89c60, uap=3D0xded66f80) at
/usr/src/sys/kern/uipc_syscalls.c:394
uap =3D (struct connect_args *) 0xded66f80
fp =3D (struct file *) 0xc3ea9640
so =3D (struct socket *) 0xdc31f480
sa =3D (struct sockaddr *) 0xc33250b0
error =3D 0
s =3D -600705920
#12 0xc02bf4ad in syscall2 (frame=3D{tf_fs =3D -1078001617, tf_es =3D 47,=
tf_ds =3D
- -1078001617, tf_edi =3D -1077983904, tf_esi =3D 59,=20
tf_ebp =3D -1077996464, tf_isp =3D -556372012, tf_ebx =3D =
673944780, tf_edx
=3D 0, tf_ecx =3D 0, tf_eax =3D 98, tf_trapno =3D 12,=20
tf_err =3D 2, tf_eip =3D 673621160, tf_cs =3D 31, tf_eflags =3D =
659, tf_esp =3D
- -1077997132, tf_ss =3D 47})
at /usr/src/sys/i386/i386/trap.c:1175
params =3D 0xbfbf11b8 "\b"
i =3D 0
callp =3D (struct sysent *) 0xc031fff0
p =3D (struct proc *) 0xded89c60
orig_tf_eflags =3D 659
sticks =3D 0
error =3D 0
narg =3D 3
args =3D {8, 135103192, 16, 0, 0, 0, 0, 0}
have_mplock =3D 1
code =3D 98
#13 0xc02ab1db in Xint0x80_syscall ()
No symbol table info available.
#14 0x2827f651 in ?? ()
No symbol table info available.
#15 0x2827fb46 in ?? ()
No symbol table info available.
#16 0x8062a75 in ?? ()
No symbol table info available.
#17 0x807177b in ?? ()
No symbol table info available.
#18 0x8058169 in ?? ()
No symbol table info available.
#19 0x80811bc in ?? ()
No symbol table info available.
#20 0x8080c42 in ?? ()
No symbol table info available.
#21 0x8081079 in ?? ()
No symbol table info available.
#22 0x8080e0d in ?? ()
No symbol table info available.
#23 0x8083052 in ?? ()
No symbol table info available.
#24 0x805184a in ?? ()
No symbol table info available.
#25 0x806e424 in ?? ()
No symbol table info available.
#26 0x804c03a in ?? ()
No symbol table info available.
(kgdb)=20
- ---Mike

Mike Tancsa (mi...@sentex.net)=09
http://www.sentex.net/mike

------------------------------

Date: Tue, 18 Mar 2003 15:06:37 +0100
From: Christoph Kukulies <ku...@physik.rwth-aachen.de>
Subject: HP-UX FS mountable?

Does anyone know whether I can mount a HP-UX (10.26) disk under FreeBSD?

- --
Chris Christoph P. U. Kukulies kuku...@rwth-aachen.de

------------------------------

Date: Tue, 18 Mar 2003 16:17:49 +0200
From: "Nikolay Y. Orlyuk" <nik...@asu.ntu-kpi.kiev.ua>
Subject: Re: some questions about ACL implementation

On Tue, Mar 18, 2003 at 08:19:15PM +0800, ouyang kai wrote:
> 1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the
> size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so
> the sum is 336.
Maybe each some structs isn't packed. I mean when you compile it align size
of some structures for ex on pargraph (16 bytes) or something like this.
>

- --
With best wishes Nikolay
mail: nik...@asu.ntu-kpi.kiev.ua

------------------------------

Date: Tue, 18 Mar 2003 10:18:22 -0500
From: Hiten Pandya <hi...@unixdaemons.com>
Subject: pmap_wired_count() macro?

Hi Gang.

Can someone enlighten me as to where I can find the
pmap_wired_count() macro? I have tried a quick grep
through sys but I am not able to find where it is.

I ask this because I was browsing through our mlock()
implementation and the 'ifndef pmap_wired_count' and
was wondering what it did. I do have an idea what this
macro would do, but I just failed to find it in our src
tree.

Thanks in advance.

-- Hiten

------------------------------

Date: Tue, 18 Mar 2003 10:45:40 -0500 (EST)
From: Daniel Ellard <ell...@eecs.harvard.edu>
Subject: Re: NFS performance tuning

The tweaks I've been working on are for read performance. Based on
what you sent, I don't think read performance is your problem at all
(although they might help you anyway, in the long run). So, my advice
might be no more useful than line noise, but here goes:

1. You've got a nfsd taking 48% of an athlon 2200? Wow.

If you can profile it to get a look at where it's spending the
time, that would be incredibly interesting. I've never seen
an nfsd do that.

2. You've got 5 network interfaces, and 2 of them are gigabit, but
you're only running 8 nfsds. By rule of thumb, I would add
more. This doesn't solve your mystery, however, because it's
the master that's eating all the CPU.

(Why do the gigabit interfaces see an order of magnitude less
traffic than the 100Mb/s?)

3. Are you using TCP or UDP? Any kind of flow control on the switch?

I'm interested to hear what other people have to say.

- -Dan

------------------------------

Date: Tue, 18 Mar 2003 17:25:01 +0200
From: Yury Tarasievich <gr...@grsu.by>
Subject: Re: fgdg

I prefer it that way:

1. run freebsd install
partition the disk, using multiplies of heads*sectors as base unit
make ...s1 slice of type 6 (and possibly make fairly big ad0s2 of
type 5)
make ...s3 and install freebsd there
(I have seen windows at my place occasionally removing primary
partitions placed in chain between C: (...s1) and extended partition)
2. setup windows to ...s1
3. when (if) wanting to run linux fdisk (I use it to add logical drives
rather than that of windows), switch bios to normal disk translation
before and to LBA after (in most cases one-time operation)

Is there any freebsd fdisk capable of dealing with logical drives?

Roman Kurakin wrote:

> Hi,
> Joerg Micheel wrote:
>
>> On Mon, Mar 17, 2003 at 12:39:22PM +0300, sergej wrote:
>>
>>
>>> mozno li ustanovit% odnovremenno na odin disk:
>>> unix i windows, i kak jto sdelat%!
>>>
> I think it would be better if you will ask questions in English.
>
>>> Get yourself a copy of the "Complete FreeBSD" by Greg Lehey,
>>> which covers this subject very well. This question also belongs
>>> to <freebsd-questions>, not -hackers.
>>>
>>> In short, the configuration option is there with FreeBSD as
>>> delivered, but you need to take care on making the right steps
>>> at the right time. Starting off with BSD first is the better
>>> way to proceed, adding Windows later.
>>>
> If you setup at first FreeBSD and then add Windows you will lose
> FreeBSD's boot loader.
> And you will have to reinstall bootloader.
>
> You also could meet other problems. If your set incorrect (from
> FreeBSD's point of view)
> geometry for you hard disk and install freebsd 5.0 after Windows 2000,
> freebsd will
> "fix" windows partition entry and any reinstalletions or fix
> procedures of Windows
> will lead to nothing. Probably some last versions from 4.x branch have
> the same
> "features", but the last 4.x version I worked with at home was 4.3.
>
>
> PS.
> I don't know if this bug was fixed in current versions. I am almost
> sure that it is not.

------------------------------

Date: Tue, 18 Mar 2003 20:51:29 +0100
From: Borje Josefsson <b...@dc.luth.se>
Subject: High CPU usage on high-bandwidth long distance connections.

Hello,

Scenario:

Two hosts:

*** Host a:
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2790.96-MHz 686-class CPU)
Hyperthreading: 2 logical CPUs
real memory =3D 1073676288 (1048512K bytes)
em0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 4470
options=3D3<rxcsum,txcsum>
media: Ethernet autoselect (1000baseSX <full-duplex>)

*** Host b:
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2790.96-MHz 686-class CPU)
Hyperthreading: 2 logical CPUs
real memory =3D 536301568 (523732K bytes)

bge0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 4470
options=3D3<rxcsum,txcsum>
media: Ethernet autoselect (1000baseSX <full-duplex>)

Both Ethernet cards are PCI-X.
=

Parameters (for both hosts):

kern.ipc.maxsockbuf=3D8388608
net.inet.tcp.rfc1323=3D1
kern.ipc.nmbclusters=3D"8192"

The hosts are connected directly (no LAN equipment inbetween) to high =

capacity backbone routers (10 Gbit/sec backbone), and are approx 1000 =

km/625 miles(!) apart. Measuring RTT gives:
RTTmax =3D 20.64 ms. Buffer size needed =3D 3.69 Mbytes, so I add 25% and=
set:

sysctl net.inet.tcp.sendspace=3D4836562 =

sysctl net.inet.tcp.recvspace=3D4836562

MTU=3D4470 all the way.

OS =3D FreeBSD 4-STABLE (as of today).

**** Now the problem:

The receiver works fine, but on the *sender* I run out if CPU (doesn't =

matter if host a or host b is sender). Measuring bandwidth with ttcp give=
s:

ttcp-t: buflen=3D61440, nbuf=3D30517, align=3D16384/0, port=3D5001 tcp
ttcp-t: 1874964480 bytes in 22.39 real seconds =3D 638.82 Mbit/sec +++
ttcp-t: 30517 I/O calls, msec/call =3D 0.75, calls/sec =3D 1362.82
ttcp-t: 0.0user 20.8sys 0:22real 93% 16i+382d 326maxrss 0+15pf 9+280csw

This is very repeatable (within a few %), and is the same regardless of =

which direction I use.

During that period, the sender shows:

0.0% user, 0.0% nice, 94.6% system, 5.4% interrupt, 0.0% idle

I have read about DEVICE_POLLING, but that doesn't seem to be supported o=
n =

any GigE PCI-X cards?!?

Does anybody have an idea on which knob to tune next to be able to fill m=
y =

(long-distance) GigE link? I am mostly interested in what to do to not ea=
t =

all my CPU, but also if there are anu other TCP parameters that I haven't=
=

thought about.

I have configured my kernel for SMP (Xeon CPU with hyperthreading), don't=
=

know if that is good or bad in this case?

With kind regards,

- --Borje

------------------------------

Date: Tue, 18 Mar 2003 13:28:31 -0800
From: Ed Mooring <emoo...@Lnxw.com>
Subject: Re: High CPU usage on high-bandwidth long distance connections.

On Tue, Mar 18, 2003 at 08:51:29PM +0100, Borje Josefsson wrote:
[snip scenario]
>
> The hosts are connected directly (no LAN equipment inbetween) to high
> capacity backbone routers (10 Gbit/sec backbone), and are approx 1000
> km/625 miles(!) apart. Measuring RTT gives:
> RTTmax = 20.64 ms. Buffer size needed = 3.69 Mbytes, so I add 25% and set:
>
> sysctl net.inet.tcp.sendspace=4836562
> sysctl net.inet.tcp.recvspace=4836562
>
> MTU=4470 all the way.
>
> OS = FreeBSD 4-STABLE (as of today).
>
> **** Now the problem:
>
> The receiver works fine, but on the *sender* I run out if CPU (doesn't
> matter if host a or host b is sender). Measuring bandwidth with ttcp gives:
>
> ttcp-t: buflen=61440, nbuf=30517, align=16384/0, port=5001 tcp
> ttcp-t: 1874964480 bytes in 22.39 real seconds = 638.82 Mbit/sec +++
> ttcp-t: 30517 I/O calls, msec/call = 0.75, calls/sec = 1362.82
> ttcp-t: 0.0user 20.8sys 0:22real 93% 16i+382d 326maxrss 0+15pf 9+280csw
>
> This is very repeatable (within a few %), and is the same regardless of
> which direction I use.
>
> During that period, the sender shows:
>
> 0.0% user, 0.0% nice, 94.6% system, 5.4% interrupt, 0.0% idle

I had something vaguely similar happen while I was porting the FreeBSD
4.2 networking stack to LynxOS. It turned out the culprit was sbappend().
It does a linear pointer chase down the mbuf chain each time you do
a write() or send(). With a high bandwidth-delay product, that chain
can get very long.

This topic came up on freebsd-net last July, and Luigi Rizzo provided
the following URL for a patch to cache the end of the mbuf chain, so
sbappend() stays O(1) instead of O(n).

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=366972+0+archive/2001/freebsd-net/20010211.freebsd-net

The subject of the July thread was 'the incredible shrinking socket', if
you want to hunt through the archives.

Hope this helps.

- --
Ed Mooring (moo...@lynuxworks.com)

------------------------------

Date: Tue, 18 Mar 2003 13:33:31 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: rumour of password aging failure in 4.7/4.8RC

I've received a few reports from teh field that password aging
with ssh in 4.7 and 4.8RC is broken.

Is there anyone out there that is using passwork expiry
and ssh? Who's the expert?

The method being used:
Define a class called the shellusers class in the /etc/login.conf.
Run cap_mkdb on the login.conf file
Go into the master.passwd file and expired an account.

According to our clients, after the account is expired SSH on 4.7
disallows any logins. It is supposed to allow your connection and then
just force you to change your password. On 4.8-RC ssh seems to be
totally ignoring the fact that the password is expired.
"login" on the other hand acts as expected.

Is this the correct procedure? (If not, what IS the correct proceedure?
Where is password expiry documented? (man login.conf and man passwd
seem the best references so far..).

How does PAM come into this?

The older version of SSH we have on the 4.4 boxes works with
the same password expiration set up without any problems.

------------------------------

Date: Tue, 18 Mar 2003 13:32:30 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: HP-UX FS mountable?

Christoph Kukulies wrote:
>
> Does anyone know whether I can mount a HP-UX (10.26) disk under FreeBSD?

FreeBSD does not support the partitioning or FS layout for HP/UX,
so you can not mount it locally. You could mount it via NFS (of
course).

According to the "5.0 way of doing things", you could implement a
"GEOM" module that would be able to deal with locating the first
block of any FS's on the volume, and from there, deal with it with
an FS module.

The actual FS layout for HP/UX FS volumes depends on the specific
version and FS type, but most of that information is documented in
the system header files, if you have them.

NetBSD for that particular hardware can mount it. I don't know
about NetBSD/i386. So that would also be a place to start.

- -- Terry

------------------------------

Date: Wed, 19 Mar 2003 01:03:38 +0300
From: Lev Serebryakov <l...@serebryakov.spb.ru>
Subject: Sound drivers

Hello, hackers! How are you?

I want to write sound driver for FreeBSD (pcm bridge driver) for
Envy24 chip and M-Audio Audiophile 2496 sound card.

Is here any documentation about pcm architecture? I've looked
through sources, but I have still some questions...

Lev Serebryakov

------------------------------

Date: Tue, 18 Mar 2003 23:11:20 +0100
From: d...@ofug.org (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Subject: Re: rumour of password aging failure in 4.7/4.8RC

Julian Elischer <jul...@elischer.org> writes:
> I've received a few reports from teh field that password aging
> with ssh in 4.7 and 4.8RC is broken.

Recent versions of OpenSSH do not support prompting the user for a new
password. I haven't tested it, but I think users with expired
passwords will simply be locked out.

> Is there anyone out there that is using passwork expiry=20
> and ssh? Who's the expert?

In the FreeBSD community, that would be me.

> How does PAM come into this?

It doesn't, really. It's a privsep problem + the fact that some of
the pertinent code has been disabled and / or left unimplemented
because it wouldn't work with privsep (so turning privsep off won't
help).

DES
- --=20
Dag-Erling Sm=F8rgrav - d...@ofug.org

------------------------------

Date: Tue, 18 Mar 2003 14:12:00 -0800
From: "Crist J. Clark" <crist...@attbi.com>
Subject: Re: ether_input: drop bdg packet

On Thu, Mar 13, 2003 at 01:13:29PM -0500, IAccounts wrote:
> I have 5.0 running as a bridge/ipfw firewall configuration, which is
> seemingly working very well in an ISP environment. However, there is
> something that I don't know if it is an error, or normal. On the console,
> I get the following message many times per second:
>
> ether_input: drop bdg packet
>
> I am suspecting that this is just a logging issue within part of the
> bridge/ipfw code, but I would like some feeback if possible to what
> exactly this is for.
>
> I have looked through bridge.c, ipfw.c, bpf.c, bpf_filter.c and many
> others for the answer. There is much reference to DROP in bridge.c, but
> nothing that looks like the console message. I would really like to find
> out why this is happening, and how to make some changes, so I would
> appreciate it if someone could point me in the direction of the code for
> this as opposed to or in addition to the answer.

The message is in src/sys/net/if_ethersubr.c. However, it was removed
in revision 1.34 which is probably why you cannot find it.
- --
Crist J. Clark | cjc...@alum.mit.edu
| cjc...@jhu.edu
http://people.freebsd.org/~cjc/ | c...@freebsd.org

------------------------------

Date: Tue, 18 Mar 2003 14:20:11 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: Re: rumour of password aging failure in 4.7/4.8RC

On Tue, 18 Mar 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote:

> Julian Elischer <jul...@elischer.org> writes:
> > I've received a few reports from teh field that password aging
> > with ssh in 4.7 and 4.8RC is broken.
>=20
> Recent versions of OpenSSH do not support prompting the user for a new
> password. I haven't tested it, but I think users with expired
> passwords will simply be locked out.
>=20
> > Is there anyone out there that is using passwork expiry=20
> > and ssh? Who's the expert?
>=20
> In the FreeBSD community, that would be me.
>=20
> > How does PAM come into this?
>=20
> It doesn't, really. It's a privsep problem + the fact that some of
> the pertinent code has been disabled and / or left unimplemented
> because it wouldn't work with privsep (so turning privsep off won't
> help).

So, the fix would be to go back to an old version of ssh?

there are patches in the OpenSSH mailing lists to make this work for
AIX. (bug '14' if that helps). I can't work out what they do however.

>=20
> DES
> --=20
> Dag-Erling Sm=F8rgrav - d...@ofug.org
>=20

------------------------------

Date: Tue, 18 Mar 2003 23:33:16 +0100
From: d...@ofug.org (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=)
Subject: Re: rumour of password aging failure in 4.7/4.8RC

Julian Elischer <jul...@elischer.org> writes:
> So, the fix would be to go back to an old version of ssh?

Yes, but you'd have to go back to a version with known remotely
exploitable vulnerabilities.

Since this is a problem for you and your customers, I will look into
getting password changing to work, at least for PAM authentication,
when I import 3.6 (which should be out in a few weeks).

DES
- --=20
Dag-Erling Sm=F8rgrav - d...@ofug.org

------------------------------

End of freebsd-hackers-digest V5 #748
*************************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message