SSH: zombie appearse probably related to PAM
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): sshd[its_pid]: error: session_by_pid: unknown pid some_pid This is harmless, because this some_pid is pid of sshd zombie, but how this zombie appearse? Why it not happens with remote login? I suspect that PAM code can be involved here, but I am not sure... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SSH: login record not present (PAM)
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 with zombie problem I report before. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: savecore
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 about it in my original mail, but
thought they weren't worth the time. What I had written and then
removed from the previous message was:
+ errno = 0;
+ ret = (int)strtol(buf, NULL, 10);
+ if (ret == 0)
+ if (errno == EINVAL || errno == ERANGE)
+ warnx(invalid value found in bounds, using 0);
I do have to admit seeing two if-statements is a bit weird :)
if (ret == 0 (...)), perhaps?
@@ -123,7 +165,20 @@
- goto closefd;
+ if (force) {
...
+ } else {
+ goto closefd;
+ }
}
I have to admit I'd write this as:
if (force == 0)
goto closefd;
/* rest of the code with one less indentation level */
But as I said, the code is fine already. But if you do commit the
(BUFSIZ * 64) change I mentioned in the earlier post, please do not
forget to mention the change and why it's done. If it makes dumps
faster to extract, without breaking the existing savecore behavior,
it's perfect :)
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: SSH: login record not present (PAM)
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 Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH: LOGIN_CAP limits ~/.login.conf not processed now
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 unsubscribe freebsd-current in the body of the message
Re: SSH: LOGIN_CAP limits ~/.login.conf not processed now
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 code written by me and present in all previous versions of OpenSSH we have, but lost in merge very recently. The real subject is improper merge. Those people who does merge not submit patches for my review. I start alarming probably a bit late since I don't have machine suitable for recent -current until now. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
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 hermes.dialup.ru Last login: Sat Apr 20 04:56:06 2002 from hermes.dialup.ru Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 ... -- The second one is semi-correct, excepting year not needed here. It is original SSH bug easy to fix, just print first 19 characters and not whole ctime() line in session.c But what about first one? Apparently it comes from pam_lastlog.so, but why there is \n in the middle? Looking at pam_lastlog.c sources I not find \n there. It seems it is inserted afterwards somehow. Notice the second \n after first lastlog line, it must not be there too. Please fix those two \n's. BTW, ONE lastlog line is enough. Please either remove pam_lastlog.so or comment #ifndef USE_PAM SSH one. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH: zombie appearse probably related to PAM
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: ssh localhost login normally and then exit. At exit you'll see following message on console (or /var/log/messages): sshd[its_pid]: error: session_by_pid: unknown pid some_pid This is harmless, because this some_pid is pid of sshd zombie, but how this zombie appearse? Why it not happens with remote login? I suspect that PAM code can be involved here, but I am not sure... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
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 back. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
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 doing this one step at a time. It'll happen much faster if you stay off my back. Sorry Dag-Erling, I not mean word 'immediately' at all, I just want to be sure that this one not forgotten in whole discussion. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
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 - /usr/src/lib/libpam/modules/pam_lastlog/pam_lastlog.c
--- /tmp/tmp.23049.0 Sat Apr 20 18:09:14 2002
+++ /usr/src/lib/libpam/modules/pam_lastlog/pam_lastlog.c Sat Apr 20 18:08:29 2002
@@ -108,15 +108,14 @@
if (lseek(fd, llpos, L_SET) != llpos)
goto file_err;
if ((flags PAM_SILENT) == 0) {
- if (read(fd, ll, sizeof(ll)) == sizeof(ll)
- ll.ll_time != 0) {
- pam_info(pamh, Last login: %.*s , 24 - 5,
- ctime(ll.ll_time));
+ if (read(fd, ll, sizeof ll) == sizeof ll ll.ll_time != 0) {
if (*ll.ll_host != '\0')
-pam_info(pamh, from %.*s\n,
+pam_info(pamh, Last login: %.*s from %.*s,
+24 - 5, ctime(ll.ll_time),
(int)sizeof(ll.ll_host), ll.ll_host);
else
-pam_info(pamh, on %.*s\n,
+pam_info(pamh, Last login: %.*s on %.*s,
+24 - 5, ctime(ll.ll_time),
(int)sizeof(ll.ll_line), ll.ll_line);
}
if (lseek(fd, llpos, L_SET) != llpos)
//depot/user/des/pam/crypto/openssh/session.c#6 - /usr/src/crypto/openssh/session.c
--- /tmp/tmp.23049.1 Sat Apr 20 18:09:15 2002
+++ /usr/src/crypto/openssh/session.c Sat Apr 20 18:04:43 2002
@@ -647,6 +647,7 @@
}
#endif
+#ifndef USE_PAM
/* Get the time and hostname when the user last logged in. */
if (options.print_lastlog) {
hostname[0] = '\0';
@@ -654,7 +655,6 @@
hostname, sizeof(hostname));
}
-#ifndef USE_PAM
/* Record that there was a login on that tty from the remote host. */
record_login(pid, s-tty, pw-pw_name, pw-pw_uid,
get_remote_name_or_ip(utmp_len, options.verify_reverse_mapping),
Re: PAM OpenSSH: two incorrect last login
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 login: Sun Apr 14 05:44:16 1991 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT (HERMES) #2: Sat Apr 20 13:06:00 MSD 2002 Newlines are gone, but see second line from back 1991 (garbadge on the stack of 'last_login_time' variable). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
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 == NULL !options.use_login !check_quietlogin(s, command) are checked. But in your variant it seems that only !check_quietlogin(s, command) checked (or, maybe it printed even unconditionally?) I am not sure here, it is internal PAM details. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
=== 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
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/fstat/fstat.c:69:
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/fs/devfs/devfs.h:63:
warning: parameter names (without types) in function declaration
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/fs/devfs/devfs.h:63:
warning: data definition has no type or storage class
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/fstat/fstat.c: In function
`devfs_filestat':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/fstat/fstat.c:610: warning:
cast from pointer to integer of different size
=== usr.bin/fsync
=== usr.bin/ftp
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ftp/../../contrib/lukemftp/src/cmds.c:
In function `fget':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ftp/../../contrib/lukemftp/src/cmds.c:717:
warning: assignment makes pointer from integer without a cast
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ftp/../../contrib/lukemftp/src/fetch.c:
In function `fetch_url':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ftp/../../contrib/lukemftp/src/fetch.c:749:
warning: assignment makes pointer from integer without a cast
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ftp/../../contrib/lukemftp/src/fetch.c:772:
warning: assignment makes pointer from integer without a cast
=== usr.bin/gencat
=== usr.bin/getopt
=== usr.bin/gprof
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/gprof/gprof.c: In function
`main':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/gprof/gprof.c:163: warning:
type mismatch in implicit declaration for built-in function `strlen'
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/gprof/gprof.c:164: warning:
type mismatch in implicit declaration for built-in function `strcpy'
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/gprof/kernel.c: In function
`kernel_getnfile':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/gprof/kernel.c:41: warning:
type mismatch in implicit declaration for built-in function `strlen'
=== usr.bin/head
=== usr.bin/hesinfo
=== usr.bin/hexdump
=== usr.bin/id
=== usr.bin/indent
=== usr.bin/ipcrm
=== usr.bin/ipcs
=== usr.bin/join
=== usr.bin/jot
=== usr.bin/kdump
In file included from ioctl.c:76:
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/sys/memrange.h:19:
warning: `MDF_ACTIVE' redefined
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/pccard/cardinfo.h:115:
warning: this is the location of the previous definition
=== usr.bin/kenv
=== usr.bin/keylogin
=== usr.bin/keylogout
=== usr.bin/killall
=== usr.bin/ktrace
=== usr.bin/ktrdump
=== usr.bin/lam
=== usr.bin/last
=== usr.bin/lastcomm
=== usr.bin/ldd
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ldd/ldd.c: In function `main':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/ldd/ldd.c:141: warning:
implicit declaration of function `ntohl'
=== usr.bin/leave
=== usr.bin/less
=== usr.bin/lessecho
=== usr.bin/lesskey
=== usr.bin/lex
=== usr.bin/lex/lib
=== usr.bin/lex/lib
=== usr.bin/limits
=== usr.bin/locate
=== usr.bin/locate/bigram
=== usr.bin/locate/code
=== usr.bin/locate/locate
=== usr.bin/lock
=== usr.bin/lockf
=== usr.bin/logger
=== usr.bin/login
=== usr.bin/logname
=== usr.bin/look
=== usr.bin/lorder
=== usr.bin/lsvfs
=== usr.bin/m4
{standard input}: Assembler messages:
{standard input}:5: Warning: unterminated string; newline inserted
{standard input}:6: Warning: unterminated string; newline inserted
cc1: warnings being treated as errors
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/m4/gnum4.c: In function
`add_sub':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/m4/gnum4.c:282: warning: int
format, different type arg (arg 2)
*** Error code 1
Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin/m4.
*** Error code 1
Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/usr.bin.
*** Error code 1
Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src.
*** Error code 1
Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src.
*** Error code 1
Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Xfree86-4 problem
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 install-time and install the wrapper port. Kris Wrapper is installed it allways has been, X starts but not the windowmanager (fluxbox or tmw) Okay, well that's not what you said, is it? :-) Please post the exact error messages. Kris msg37452/pgp0.pgp Description: PGP signature
Re: Xfree86-4 problem
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
Re: Xfree86-4 problem
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 got at install-time and install the wrapper port. Kris Wrapper is installed it allways has been, X starts but not the windowmanager (fluxbox or tmw) Okay, well that's not what you said, is it? :-) Please post the exact error messages. Kris 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: 16472 XFree86: client 1 rejected from local host AUDIT: Fri Apr 19 22:09:17 2002: 16472 XFree86: client 1 rejected from local host AUDIT: Fri Apr 19 22:09:19 2002: 16472 XFree86: client 1 rejected from local host /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xfree86-4 problem
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: 16472 XFree86: client 1 rejected from local host AUDIT: Fri Apr 19 22:09:17 2002: 16472 XFree86: client 1 rejected from local host AUDIT: Fri Apr 19 22:09:19 2002: 16472 XFree86: client 1 rejected from local host Do you have a hostname? I've found that X does this without one set. For the purposes of X, it doesn't appear to matter if it maps to an address or not. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg37455/pgp0.pgp Description: PGP signature
Re: Adding a 'bpf' group for /dev/bpf*
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 effective gid of 'bpf' instead of the current requirement for an effective user of root. I've been running this way on many of our servers for several months now, and things like snort, tcpdump, etc., are quite happy with it (under stable). I do this a lot too on systems where it makes sense. But I'm not sure I understand what you are asking to be done. Is it asking too much of an administrator to do, # echo 'sniff:*:80:list of users' /etc/group # chown root:sniff /dev/bpf* # chmod 640 /dev/bpf* To do the appropriate customizations? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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 administrator to do,
There are two ways to handle this. One is to modify the ports builds to
conditionally create a 'bpf' group. This requires the ports all agree
on the group, and I don't like the idea of a port install messing with
permissions and ownerships of things in /dev (which aren't sticky across
reboots, anyway). If the OS sets the access policy there cannot be any
confusion.
OK. Now you've really lost me. What do ports have to do with this?
Which ports? None of the sniffing programs I am aware of use
set{g,u}id bits. They rely on the permissions of the user running
them.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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 increase to avoid that crash? I've tried increasing maxusers from 512-1024, but *if* that works, I imagine I'm raising a bunch of limits (and using memory) that I don't have to ... The server is a Dual-CPU PIII-1Ghz with 3Gig of RAM and ~3Gig of swap space right now ... the data drive is 5x18gig drives in a RAID5 configuration (hardware RAID, not vinum) ... I ran top in an xterm so that I could see what was up just before the crash, and the results were: last pid: 84988; load averages: 19.82, 57.35, 44.426 up 0+23:33:12 02:05:00 5021 processes:16 running, 5005 sleeping CPU states: 8.7% user, 0.0% nice, 24.3% system, 2.2% interrupt, 64.7% idle Mem: 2320M Active, 211M Inact, 390M Wired, 92M Cache, 199M Buf, 4348K Free Swap: 3072M Total, 1048M Used, 2024M Free, 34% Inuse, 448K Out So, I have plenty of swapspace left, lots of idle CPU and a whole whack of processes ... Now, looking at the LINT file, there appears to be *alot* of things I *could* change ... for instance, NSFBUFS, KVA_FILES, etc ... but I don't imagine that changing these blindly is particularly wise ... so, how do you determine what to change? For instance, at a maxusers of 512, NSFBUFS should be ~8704, and if I've only got 5000 processes running, chances are I'm still safe at that value, no? But sysctl doesn't show any 'sf_buf' value, so how do I figure out what I'm using? Basically, are there any commands similar to netstat -m for nmbclusters that I can run to 'monitor' and isolate where I'm exhausting these resources? Is there a doc on this sort of stuff that I should be reading for this? Something that talks about kernel tuning for high-load/processes servers? Thanks for any help in advance .. --- machine i386 cpu I686_CPU ident kernel maxusers1024 options NMBCLUSTERS=15360 options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM options SHMMAXPGS=98304 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SYSVSEM options SEMMNI=2048 options SEMMNS=4096 options SYSVMSG #SYSV-style message queues options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device amr # AMI MegaRAID device sym device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0at atkbdc? irq 12 device vga0at isa? pseudo-device splash device sc0 at isa? flags 0x100 device npx0at nexus? port IO_NPX irq 13 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty 256 # Pseudo-ttys (telnet etc) pseudo-device gif # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) pseudo-device bpf #Berkeley packet filter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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.
Sorry -- keyboard and brain disconnect on my part. What I was trying to
get at was the need to run sniffers as root by default. The fewer
things that need to be run as root, the better (e.g. I don't want snort
and trafdump running as root on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps and top.
--lyndon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
uthread_init.c again
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 calls that create fds) need to
check, if the newly created fd is a stdio one and adjust
_pthread_stdio_flags - at least this is my understanding of this voodoo.
but then, i don't have the faintest idea of what i'm talking about. :)
greetings
ps: flames must be explicitly cc'd to me. :)
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
The problem with making software idiot-proof is that idiots are so clever.
Index: uthread_init.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v
retrieving revision 1.38
diff -u -r1.38 uthread_init.c
--- uthread_init.c 19 Mar 2002 22:58:56 - 1.38
+++ uthread_init.c 20 Apr 2002 22:42:19 -
-173,31 +173,6
if ((references[0] == NULL) || (libgcc_references[0] == NULL))
PANIC(Failed loading mandatory references in _thread_init);
- /*
-* Check for the special case of this process running as
-* or in place of init as pid = 1:
-*/
- if (getpid() == 1) {
- /*
-* Setup a new session for this process which is
-* assumed to be running as root.
-*/
- if (setsid() == -1)
- PANIC(Can't set session ID);
- if (revoke(_PATH_CONSOLE) != 0)
- PANIC(Can't revoke console);
- if ((fd = __sys_open(_PATH_CONSOLE, O_RDWR)) 0)
- PANIC(Can't open console);
- if (setlogin(root) == -1)
- PANIC(Can't set login to root);
- if (__sys_ioctl(fd,TIOCSCTTY, (char *) NULL) == -1)
- PANIC(Can't set controlling terminal);
- if (__sys_dup2(fd,0) == -1 ||
- __sys_dup2(fd,1) == -1 ||
- __sys_dup2(fd,2) == -1)
- PANIC(Can't dup2);
- }
-
/* Get the standard I/O flags before messing with them : */
for (i = 0; i 3; i++)
if (((_pthread_stdio_flags[i] =
-213,6 +188,16
/* Cannot create pipe, so abort: */
PANIC(Cannot create kernel pipe);
}
+ /*
+* Make sure the pipe does not get in the way of stdio:
+*/
+ for (i = 0; i 2; i++)
+ if (_thread_kern_pipe[i] 3) {
+ if ((fd = __sys_fcntl(_thread_kern_pipe[i], F_DUPFD, 3)) == -1)
+ PANIC(Cannot create kernel pipe);
+ __sys_close(_thread_kern_pipe[i]);
+ _thread_kern_pipe[i] = fd;
+ }
/* Get the flags for the read pipe: */
else if ((flags = __sys_fcntl(_thread_kern_pipe[0], F_GETFL, NULL)) == -1) {
/* Abort this application: */
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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 reduced my maxusers to 256 from 1024, since 1024 was crashing worse then 512, and I ran across the 'tuning' man page that stated that you shouldn't go above 256 :( Just a bit more detail on the setup ... On Sat, 20 Apr 2002, 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 determine what 'resources' I need to increase to avoid that crash? I've tried increasing maxusers from 512-1024, but *if* that works, I imagine I'm raising a bunch of limits (and using memory) that I don't have to ... The server is a Dual-CPU PIII-1Ghz with 3Gig of RAM and ~3Gig of swap space right now ... the data drive is 5x18gig drives in a RAID5 configuration (hardware RAID, not vinum) ... I ran top in an xterm so that I could see what was up just before the crash, and the results were: last pid: 84988; load averages: 19.82, 57.35, 44.426 up 0+23:33:12 02:05:00 5021 processes:16 running, 5005 sleeping CPU states: 8.7% user, 0.0% nice, 24.3% system, 2.2% interrupt, 64.7% idle Mem: 2320M Active, 211M Inact, 390M Wired, 92M Cache, 199M Buf, 4348K Free Swap: 3072M Total, 1048M Used, 2024M Free, 34% Inuse, 448K Out So, I have plenty of swapspace left, lots of idle CPU and a whole whack of processes ... Now, looking at the LINT file, there appears to be *alot* of things I *could* change ... for instance, NSFBUFS, KVA_FILES, etc ... but I don't imagine that changing these blindly is particularly wise ... so, how do you determine what to change? For instance, at a maxusers of 512, NSFBUFS should be ~8704, and if I've only got 5000 processes running, chances are I'm still safe at that value, no? But sysctl doesn't show any 'sf_buf' value, so how do I figure out what I'm using? Basically, are there any commands similar to netstat -m for nmbclusters that I can run to 'monitor' and isolate where I'm exhausting these resources? Is there a doc on this sort of stuff that I should be reading for this? Something that talks about kernel tuning for high-load/processes servers? Thanks for any help in advance .. --- machine i386 cpu I686_CPU ident kernel maxusers 1024 options NMBCLUSTERS=15360 options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM options SHMMAXPGS=98304 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SYSVSEM options SEMMNI=2048 options SEMMNS=4096 options SYSVMSG #SYSV-style message queues options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O deviceisa devicepci devicescbus # SCSI bus (required) deviceda # Direct Access (disks) devicesa # Sequential Access (tape etc) devicecd # CD devicepass# Passthrough device (direct SCSI access) deviceamr # AMI MegaRAID device sym deviceatkbdc0 at isa? port IO_KBD deviceatkbd0 at atkbdc? irq 1 flags 0x1 devicepsm0at atkbdc? irq 12 devicevga0at isa? pseudo-device splash devicesc0 at isa? flags 0x100 devicenpx0at nexus? port IO_NPX irq 13 devicesio0at isa? port IO_COM1 flags 0x10 irq 4 devicesio1at isa? port IO_COM2 irq 3 devicemiibus # MII bus support devicefxp # Intel
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
* 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 vm.swap_idle_enabled=1 vfs.vmiodirenable=1 kern.ipc.somaxconn=4096 I've also just reduced my maxusers to 256 from 1024, since 1024 was crashing worse then 512, and I ran across the 'tuning' man page that stated that you shouldn't go above 256 :( Just a bit more detail on the setup ... You said you're running 5000 processes. 5000 processes of what? Are they useing SYSVSHM? If so, this sysctl might help: kern.ipc.shm_use_phys=1 It'll only work if you set it before your processes setup. Some more information about what these 5000 processes are doing would help. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: savecore
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 Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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: kern.maxfiles=65534 jail.sysvipc_allowed=1 vm.swap_idle_enabled=1 vfs.vmiodirenable=1 kern.ipc.somaxconn=4096 I've also just reduced my maxusers to 256 from 1024, since 1024 was crashing worse then 512, and I ran across the 'tuning' man page that stated that you shouldn't go above 256 :( Just a bit more detail on the setup ... You said you're running 5000 processes. 5000 processes of what? Are they useing SYSVSHM? If so, this sysctl might help: kern.ipc.shm_use_phys=1 Okay, never knew of that one before ... have it set for the next reboot, as I do have a few postgresql servers going on the 'root (non-jail)' server ... 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 ... normally, it hovers around 2700 processes ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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 determine what 'resources' I need to increase to avoid that crash? I've tried increasing maxusers from 512-1024, but *if* that works, I imagine I'm raising a bunch of limits (and using memory) that I don't have to ... The server is a Dual-CPU PIII-1Ghz with 3Gig of RAM and ~3Gig of swap space right now ... the data drive is 5x18gig drives in a RAID5 configuration (hardware RAID, not vinum) ... You have more memory than you can allocate kernel memory to provide page table entries for. The only solution is to increase your kernel virtual address space size to accomodate the page mappings. How to do this varies widely by the version of FreeBSD you are using, and, unless you read NOTES and are running a recent -current, is not incredibly well documented, and requires an understanding of how the virtual address space is laid out and managed (which is also not well documented anywhere). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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 ... normally, it hovers around 2700 processes ... Sounds like my laptop. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
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() called on cpu#1 Great ... but, how do I determine what 'resources' I need to increase to avoid that crash? I've tried increasing maxusers from 512-1024, but *if* that works, I imagine I'm raising a bunch of limits (and using memory) that I don't have to ... The server is a Dual-CPU PIII-1Ghz with 3Gig of RAM and ~3Gig of swap space right now ... the data drive is 5x18gig drives in a RAID5 configuration (hardware RAID, not vinum) ... You have more memory than you can allocate kernel memory to provide page table entries for. The only solution is to increase your kernel virtual address space size to accomodate the page mappings. How to do this varies widely by the version of FreeBSD you are using, and, unless you read NOTES and are running a recent -current, is not incredibly well documented, and requires an understanding of how the virtual address space is laid out and managed (which is also not well documented anywhere). Ya, this is the roadblock I'm hitting :( I'm running 4.5-STABLE here, as of this afternoon ... thoughts/suggestiosn based on that? Also, is there somethign that I can run to monitor this, similar to running netstat -m to watch nmbclusters? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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. They rely on the permissions of the
Crist user running them.
Sorry -- keyboard and brain disconnect on my part. What I was trying to
get at was the need to run sniffers as root by default. The fewer
things that need to be run as root, the better (e.g. I don't want snort
and trafdump running as root on my firewalls if I can avoid it).
Programs like snort can attempt to lose uid-0 after opening the bpf
device, but others like tcpdump do not.
As David Wolfskill mentioned in a previous message, this idea is the
same as how the operator group is used for dump. kmem did the same
thing for ps and top.
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. When
tcpdump(1) or one of these ports is installed, there is no reason to
give it any special group ownership. The thing that determines whether
someone can sniff is the {u,g}id of the user executing the
command. The port's Makefile doesn't need to know anything about your
/etc/group; it just installs the file -r-xr-x-r-x root:wheel. The
local administrator simply needs to execute the simple commands I put
in my last mail to give a group sniffing powers. The files'
permissions and ownership are never changed.
Since the ports would really make no use of a preordained 'bpf' group,
I still don't see what purpose it really serves to add one. I really
hesitate to add groups and change default ownerships after seeing the
_steady_ stream of mail that the smmsp:smmsp ownership of
/var/spool/mqueue the sendmail(8) upgrade created.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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. When
tcpdump(1) or one of these ports is installed, there is no reason to
give it any special group ownership. The thing that determines whether
someone can sniff is the {u,g}id of the user executing the
command. The port's Makefile doesn't need to know anything about your
/etc/group; it just installs the file -r-xr-x-r-x root:wheel. The
local administrator simply needs to execute the simple commands I put
in my last mail to give a group sniffing powers. The files'
permissions and ownership are never changed.
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? Or should we just put the appropriate commands in rc.local ?
Besides bpf, this would be useful, for example, for people who want to
change permissions on cd-rom devices to 644 so that non-root users can make
iso images (or give a special group cd burner rights).
Craig
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: uthread_init.c again
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 untested). note, that the open() wrapper (and other calls that create fds) need to check, if the newly created fd is a stdio one and adjust _pthread_stdio_flags - at least this is my understanding of this voodoo. but then, i don't have the faintest idea of what i'm talking about. :) I like this patch better :-) Thanks, -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
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 great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xfree86-4 problem
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 | Directable Mirrors The computer obeys and wins.|A Better Way To Focus The Sun You lose and Bill collects. | licenses available - see: | http://www.sohara.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
