WARNING: this bug present even _before_ my changes, tested with session.c
v1.22
It happens only with 'localhost' and not in remote case. To
reproduce it, call:
ssh localhost
login normally and then exit. At exit you'll see following message on
console (or /var/log/messages):
WARNING: this bug appearse even _before_ my changes, I test it with
session.c v1.22
When you log in, locally or remotely, login record not added, logged user
is invisible for 'w' or 'who'. Of course, !use_login assumed. Yes, I have
updated /etc/pam.d
Please fix it.
Perhaps it somehow related
On 2002-04-19 21:00, Chad David wrote:
I was actually hoping for a few more comments on the code, but thanks
anyway ;).
Nah... Most of the code looks OK, as far as I can tell. I'm not a C
guru or something similar, but it is fine. Style things like the two
below were what I had written
Andrey A. Chernov [EMAIL PROTECTED] writes:
When you log in, locally or remotely, login record not added, logged user
is invisible for 'w' or 'who'. Of course, !use_login assumed. Yes, I have
updated /etc/pam.d
Please fix it.
I postd a patch to -current yesterday.
DES
--
Dag-Erling
Andrey A. Chernov [EMAIL PROTECTED] writes:
NOTE: I just commit the fix, see session.c commit log for detailed
explanation.
Andrey, in the future please *submit patches for review*.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
On Sat, Apr 20, 2002 at 17:12:21 +0200, Dag-Erling Smorgrav wrote:
Andrey A. Chernov [EMAIL PROTECTED] writes:
NOTE: I just commit the fix, see session.c commit log for detailed
explanation.
Andrey, in the future please *submit patches for review*.
This case is special - that was old
This bug still present too. Please handle it somehow, it is clearly comes
from PAM.
On Sat, Apr 20, 2002 at 05:16:35 +0400, Andrey A. Chernov wrote:
I got this TWO last login lines with recent -current SSH+PAM:
--
Last login: Sat Apr 20 04:50:45
from
This one still present, libutil/login.c commit not fix it.
On Sat, Apr 20, 2002 at 14:19:55 +0400, Andrey A. Chernov wrote:
WARNING: this bug present even _before_ my changes, tested with session.c
v1.22
It happens only with 'localhost' and not in remote case. To
reproduce it, call:
Andrey A. Chernov [EMAIL PROTECTED] writes:
This bug still present too. Please handle it somehow, it is clearly comes
from PAM.
Andrey, it's quite possible that you're Superman, but I'm not, so GIVE
ME A BREAK. I'm doing this one step at a time. It'll happen much
faster if you stay off my
On Sat, Apr 20, 2002 at 18:01:58 +0200, Dag-Erling Smorgrav wrote:
Andrey A. Chernov [EMAIL PROTECTED] writes:
This bug still present too. Please handle it somehow, it is clearly comes
from PAM.
Andrey, it's quite possible that you're Superman, but I'm not, so GIVE
ME A BREAK. I'm
Andrey A. Chernov [EMAIL PROTECTED] writes:
I got this TWO last login lines with recent -current SSH+PAM:
See attached patch.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
//depot/user/des/pam/lib/libpam/modules/pam_lastlog/pam_lastlog.c#9 -
On Sat, Apr 20, 2002 at 18:10:50 +0200, Dag-Erling Smorgrav wrote:
Andrey A. Chernov [EMAIL PROTECTED] writes:
I got this TWO last login lines with recent -current SSH+PAM:
See attached patch.
It goes better and worse in the same time :-)
Last login: Sat Apr 20 20:16:55 on ttyv4
Last
On Sat, Apr 20, 2002 at 20:20:01 +0400, Andrey A. Chernov wrote:
Newlines are gone, but see second line from back 1991 (garbadge on the
stack of 'last_login_time' variable).
BTW, please notice that printing this line is very conditionalized in
OpenSSH:
options.print_lastlog
command ==
=== usr.bin/enigma
=== usr.bin/env
=== usr.bin/expand
=== usr.bin/false
=== usr.bin/fetch
=== usr.bin/file
=== usr.bin/file2c
=== usr.bin/find
=== usr.bin/finger
=== usr.bin/fmt
=== usr.bin/fold
=== usr.bin/from
=== usr.bin/fstat
In file included from
On Sat, Apr 20, 2002 at 12:02:11AM +0200, John Angelmo wrote:
Kris Kennaway wrote:
On Fri, Apr 19, 2002 at 10:13:23PM +0200, John Angelmo wrote:
After yesterdays new build I found a problem
Xfree86-4 can't start as regular user (exept root)
Read the fine message you got at
On Fri, Apr 19, 2002 at 08:56:50PM -0700, James Satterfield wrote:
I've found that wrapper needs to be updated with XFree86-4.
wrapper always needs to be rebuilt when you update X, yes.
Kris
msg37453/pgp0.pgp
Description: PGP signature
Kris Kennaway wrote:
On Sat, Apr 20, 2002 at 12:02:11AM +0200, John Angelmo wrote:
Kris Kennaway wrote:
On Fri, Apr 19, 2002 at 10:13:23PM +0200, John Angelmo wrote:
After yesterdays new build I found a problem
Xfree86-4 can't start as regular user (exept root)
Read the fine message you
On Sat, Apr 20, 2002 at 10:39:22PM +0200, John Angelmo wrote:
Well X starts but just to the gray area, no windowmanager starts and the
error I get(after I have exited) is:
AUDIT: Fri Apr 19 22:09:13 2002: 16472 XFree86: client 1 rejected from
local host
AUDIT: Fri Apr 19 22:09:15 2002:
On Sat, Apr 20, 2002 at 03:39:14PM -0600, Lyndon Nerenberg wrote:
For the benefit of packet sniffers and other things that only want
read-only access to /dev/bpf*, what do people think of adding a 'bpf'
group for those programs? This allows bpf devices to be read by
programs running with an
On Sat, Apr 20, 2002 at 04:02:13PM -0600, Lyndon Nerenberg wrote:
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist I do this a lot too on systems where it makes sense. But I'm
Crist not sure I understand what you are asking to be done. Is it
Crist asking too much of an
Over the past week, I've been trying to get information on how to fix a
server that panics with:
| panic: vm_map_entry_create: kernel resources exhausted
| mp_lock = 0101; cpuid = 1; lapic.id = 0100
| boot() called on cpu#1
Great ... but, how do I determine what 'resources' I need to
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist OK. Now you've really lost me. What do ports have to do with
Crist this? Which ports? None of the sniffing programs I am aware
Crist of use set{g,u}id bits. They rely on the permissions of the
Crist user running them.
hello,
this is again about the _thread_kern_pipe issue raised a few days ago.
thinking about it again, it's nonsense to create any pid-specific
workarounds by creating fake stdio. the solution is straightforward;
patch attached (completely untested).
note, that the open() wrapper (and other
As a quick follow-up to this, doing more searching on the web, I came
across a few suggested 'sysctl' settings, which I've added to what I had
before, for a total of:
kern.maxfiles=65534
jail.sysvipc_allowed=1
vm.swap_idle_enabled=1
vfs.vmiodirenable=1
kern.ipc.somaxconn=4096
I've also just
* The Hermit Hacker [EMAIL PROTECTED] [020420 16:01] wrote:
As a quick follow-up to this, doing more searching on the web, I came
across a few suggested 'sysctl' settings, which I've added to what I had
before, for a total of:
kern.maxfiles=65534
jail.sysvipc_allowed=1
Yes, I'm in favor of going back to the simple sequence number too.
I don't understand the advantage of the MD5.
While you're in there, could you put back minfree checking too?
That bit me pretty badly today, with savecore filling up my /var
because it doesn't care about minfree.
Bill
To
On Sat, 20 Apr 2002, Alfred Perlstein wrote:
* The Hermit Hacker [EMAIL PROTECTED] [020420 16:01] wrote:
As a quick follow-up to this, doing more searching on the web, I came
across a few suggested 'sysctl' settings, which I've added to what I had
before, for a total of:
Marc G. Fournier wrote:
Over the past week, I've been trying to get information on how to fix a
server that panics with:
| panic: vm_map_entry_create: kernel resources exhausted
| mp_lock = 0101; cpuid = 1; lapic.id = 0100
| boot() called on cpu#1
Great ... but, how do I
Marc G. Fournier wrote:
It'll only work if you set it before your processes setup.
Some more information about what these 5000 processes are doing
would help.
Sorry ... the server is running ~210 jails ... so the '5k processes' would
be when they all start up their periodic scripts
On Sat, 20 Apr 2002, Terry Lambert wrote:
Marc G. Fournier wrote:
Over the past week, I've been trying to get information on how to fix a
server that panics with:
| panic: vm_map_entry_create: kernel resources exhausted
| mp_lock = 0101; cpuid = 1; lapic.id = 0100
| boot()
On Sat, Apr 20, 2002 at 04:27:18PM -0600, Lyndon Nerenberg wrote:
Crist == Crist J Clark [EMAIL PROTECTED] writes:
Crist OK. Now you've really lost me. What do ports have to do with
Crist this? Which ports? None of the sniffing programs I am aware
Crist of use set{g,u}id bits.
Crist J. Clark wrote:
These are actually very different in that they are set{u,g}id commands
(well, ps(1) is not set{u,g}id anymore and is root:wheel owned). The
sniffing tools we've been discussing, and pretty much all of the ones
I've used, tcpdump(1), snort(8), nmap(1), etc., are not.
On Sun, 21 Apr 2002, Oswald Buddenhagen wrote:
hello,
this is again about the _thread_kern_pipe issue raised a few days ago.
thinking about it again, it's nonsense to create any pid-specific
workarounds by creating fake stdio. the solution is straightforward;
patch attached (completely
On Sat, 20 Apr 2002, Craig Boston wrote:
Since -current by default uses devfs, is there a standard way to make the
ownership/permissions of device nodes sticky so that they persist across
boots?
rc.devfs
--
We have known freedom's price. We have shown freedom's power.
And in this
On Sat, 20 Apr 2002 13:35:32 -0700
Kris Kennaway [EMAIL PROTECTED] wrote:
KK wrapper always needs to be rebuilt when you update X, yes.
All you really need to do is reset the X symlink (unless you are
upgrading from 3 to 4 in which case you need a new wrapper).
--
C:WIN
35 matches
Mail list logo
