Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown <[EMAIL PROTECTED]> wrote: > While you're enhancing cdboot anyway, can I ask how complicated it > would be to make cdboot serial-console capable? (I'm not a C > programmer, I'm a sysadmin - but I'd be prepared to try and look at > this myself if no-one else is interested). > > As it stands, the only way I've found to do a serial-console CD-based > installation is by enabling the serial console in /boot/loader.conf, > by which time you've already missed several useful points, > particularly the entry to BIOS settings (if you have a serial-capable > BIOS). cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs panics
> > Hi, > > On 2008-12-10, Danny Braniss wrote: > > from a solaris or linux client, doing a ls(1) of a nfs exported zfs > > file, > > for example: ls /net/zfs-server/h/.zfs/snapshot, > > panics the server. The server is running latest 7.1-prerelease. > > This has been reported as PR kern/125149. I have described the problem > in this message: > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html > > See the PR for RELENG_7 patches. > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) > > -- > Jaakko Hi Jaakko, did you apply the patches and it solved the problem? and, btw, which patch? To Jeremy, How about adding a line explaining that it would be prudent to 'zfs set snapdir=hidden' ..., or, of cource fix the bug :-) I will apply the patch/es and see what happens. cheers, danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NTP: leap second adjustments.
Hello Hackers, I am working on ntpd 4.2.0-a. I need to test whether this version of ntpd is capable of handling leap second adjustments. Could any one please let me know any details of how i can simulate the leap count adjustments. I need to verify if the system does not crash with leap second and works fine. Thanks, Vasanth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: zfs panics
> > > > Hi, > > > > On 2008-12-10, Danny Braniss wrote: > > > from a solaris or linux client, doing a ls(1) of a nfs exported zfs > > > file, > > > for example: ls /net/zfs-server/h/.zfs/snapshot, > > > panics the server. The server is running latest 7.1-prerelease. > > > > This has been reported as PR kern/125149. I have described the problem > > in this message: > > > > http://lists.freebsd.org/pipermail/freebsd-fs/2008-October/005217.html > > > > See the PR for RELENG_7 patches. > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125149) > > > > -- > > Jaakko > > Hi Jaakko, > did you apply the patches and it solved the problem? > and, btw, which patch? > > To Jeremy, > How about adding a line explaining that it would be > prudent to 'zfs set snapdir=hidden' ..., or, of cource > fix the bug :-) > I will apply the patch/es and see what happens. > > cheers, > danny the patch to nfs_server.c does indeed prevent the panics. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small Change to chpass.c
On 10/12/08 18:00 -0800, Sheldon Givens wrote:
> Hi guys,
>
> When I was doing some user management today I noticed that chpass, and all
> the utilities that use chpass.c, only give one attempt to authenticate to
> make the change. After I messed this up once or twice (and after doing 4-5
> minutes of editing only to have it lost when I typo'd the password) I wrote
> this little change in to chpass.c.
>
> When it needs the users password, it will enter into a for loop, increasing
> itr until it hits max_retries (defined at top of main() declaration). If one
> of these tries is successful (password given matches) then auth is set to
> '1' and we break from the loop, and update info. If, after three tries, auth
> is still '0' (the user didn't supply the proper password) we call baduser()
> to handle it.
>
> It's a pretty inconsequential change but it managed to relieve me of quite a
> bit of stress :-)
>
> Happy Holidays, everyone!
>
> Sheldon Givens
>
>
>
> ---snip---
> --- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
> +++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
> @@ -80,10 +80,11 @@
> {
> enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
> struct passwd lpw, *old_pw, *pw;
> - int ch, pfd, tfd;
> + int ch, pfd, tfd, itr, auth;
> const char *password;
> char *arg = NULL;
> uid_t uid;
> + int max_retries = 3;
> #ifdef YP
> struct ypclnt *ypclnt;
> const char *yp_domain = NULL, *yp_host = NULL;
> @@ -227,9 +228,16 @@
> }
>
> if (old_pw && !master_mode) {
> - password = getpass("Password: ");
> - if (strcmp(crypt(password, old_pw->pw_passwd),
> - old_pw->pw_passwd) != 0)
> + auth = 0;
> + for(itr=0;itr + password = getpass("Password:");
> + if(strcmp(crypt(password, old_pw->pw_passwd),
> + old_pw->pw_passwd) == 0) {
> + auth=1;
> + break;
> + }
> + }
> + if (!auth)
> baduser();
> } else {
> password = "";
> ---snip---
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hi,
Sure, your patch solves some admins nightmares :)
Bus it impacts the scripts or applications using chpass interactively, no?
- Rodrigo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Thursday 11 December 2008 10:45:41 Giorgos Keramidas wrote: > On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown <[EMAIL PROTECTED]> wrote: > > While you're enhancing cdboot anyway, can I ask how complicated it > > would be to make cdboot serial-console capable? (I'm not a C > > programmer, I'm a sysadmin - but I'd be prepared to try and look at > > this myself if no-one else is interested). > > > > As it stands, the only way I've found to do a serial-console CD-based > > installation is by enabling the serial console in /boot/loader.conf, > > by which time you've already missed several useful points, > > particularly the entry to BIOS settings (if you have a serial-capable > > BIOS). > > cdboot runs long after the prompt for BIOS setup. I don't think we can > modify cdboot to add serial console support to systems whose BIOS setup > doesn't support it. Sorry, of course you're right: I'm talking nonsense. It's the stage immediately after that that isn't available. I wish I could remember why I thought that had caused me a problem once. Certainly there's a big chunk of the boot process that is accessible through a serial console on a disk-based boot that's not available on a serial-console boot. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown <[EMAIL PROTECTED]> wrote: >> cdboot runs long after the prompt for BIOS setup. I don't think we >> can modify cdboot to add serial console support to systems whose BIOS >> setup doesn't support it. > > Sorry, of course you're right: I'm talking nonsense. > > It's the stage immediately after that that isn't available. I wish I > could remember why I thought that had caused me a problem once. > > Certainly there's a big chunk of the boot process that is accessible > through a serial console on a disk-based boot that's not available on > a serial-console boot. I'm still not sure what sort of `serial console boot' we are talking about here. What's the difference between a `serial console on a disk-based boot' and a `serial console boot'? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Thursday 11 December 2008 14:42:46 Giorgos Keramidas wrote: > On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown <[EMAIL PROTECTED]> wrote: > >> cdboot runs long after the prompt for BIOS setup. I don't think we > >> can modify cdboot to add serial console support to systems whose BIOS > >> setup doesn't support it. > > > > Sorry, of course you're right: I'm talking nonsense. > > > > It's the stage immediately after that that isn't available. I wish I > > could remember why I thought that had caused me a problem once. > > > > Certainly there's a big chunk of the boot process that is accessible > > through a serial console on a disk-based boot that's not available on > > a serial-console boot. > > I'm still not sure what sort of `serial console boot' we are talking > about here. What's the difference between a `serial console on a > disk-based boot' and a `serial console boot'? Sorry, there's been an element of ``ready - fire - aim'' about my messages today - I'm trying to do several other things at once. Let me get a serial-boot CD out and play with it - it's a while since I did a headless install so I'm working from a vague memory. I think what I'm saying is that there are several stages in the boot process; when booting from a hard drive and using a serial console, all the stages are accessible: but when booting from a CD, only the last stage is. I seem to remember that causing me a problem with a headless machine once upon a time (perhaps there was an error at an early stage, with the first hard drive failing, and I couldn't see loader(8) to tell it to boot off the second drive which was a mirror of the first?). Certainly I've taken part in a couple of discussions in -questions over the last year or two in which people want to know how to make a serial-capable install CD - which is not as straightforward as it might be if there were a serial-capable cdboot (along the same lines as putting boot0sio instead of boot0 on a hard drive). Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small Change to chpass.c
On Thu, 11 Dec 2008 08:11:20 +0100 (CET), Trond Endrestøl <[EMAIL PROTECTED]>
wrote:
>On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
>> On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens" <[EMAIL PROTECTED]>
>> wrote:
>> > --- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
>> > +++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
>> > @@ -80,10 +80,11 @@
>> > {
>> > enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>> > struct passwd lpw, *old_pw, *pw;
>> > - int ch, pfd, tfd;
>> > + int ch, pfd, tfd, itr, auth;
>> > const char *password;
>> > char *arg = NULL;
>> > uid_t uid;
>> > + int max_retries = 3;
>> > #ifdef YP
>> > struct ypclnt *ypclnt;
>> > const char *yp_domain = NULL, *yp_host = NULL;
>> > @@ -227,9 +228,16 @@
>> > }
>> >
>> > if (old_pw && !master_mode) {
>> > - password = getpass("Password: ");
>
> I'm sure you have noticed the trailing space in the string.
>
>> > - if (strcmp(crypt(password, old_pw->pw_passwd),
>> > - old_pw->pw_passwd) != 0)
>> > + auth = 0;
>> > + for(itr=0;itr> > + password = getpass("Password:");
>
> The space's missing in this string. It might be better to stay
> consistent with the original code.
Good catch. No, I didn't notice the missing space the first time I read
the diff :/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
This sounds and looks cool, diff looks OK (haven't applied), Luigi's comments seem well thought out and expressed. cheers BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
(no subject)
Okay, new problem with regard to netgroups, NIS, and Pam: Given the following situation: * I want to be able to have su work normally in the event of an NIS disconnect, since I will likely need to su to fix said disconnect. * The wheel group needs to stay local * I want su to still use group ownership as a check I recently could not get an admin account (defined in NIS) to su to root. Even though "groups username" showed he was in wheel (and the wheel group has been propagated into NIS), pam_group and pw groupshow show him as not.) This is probably because the local wheel group overrode the NIS wheel group. (I'm not that thrilled by having the wheel group in NIS anyway). Since pam_group is "requisite", there's no easy way to call it multiple times, and no easy pam syntax to say "one of these two must pass". Required won't help, Otherwise I'd simply define an extra group, call it NISwheel or something, and configure access accordingly. What I instead would propose is for pam_group to take an optional argument list instead of a single group (or possibly, multiple group= requirements). Doing something with pam_exec is an option here as well, but I feel this functionality should be fairly elementary to add, moving forward. -Dan -- "You're a daddy. I'm a mommy. She's our baby. Deal with it." -Cali, 11/7/02, about 1:35 AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Small Change to chpass.c
On Thu, Dec 11, 2008 at 5:15 AM, Giorgos Keramidas
wrote:
> On Thu, 11 Dec 2008 08:11:20 +0100 (CET), Trond Endrestøl
> wrote:
>>On Thu, 11 Dec 2008 08:32+0200, Giorgos Keramidas wrote:
>>> On Wed, 10 Dec 2008 18:00:25 -0800, "Sheldon Givens"
>>> wrote:
>>> > --- /usr/src/usr.bin/chpass.c 2008-12-11 01:55:27.0 -0800
>>> > +++ /usr/src/usr.bin/chpass.c 2008-12-11 01:57:09.0 -0800
>>> > @@ -80,10 +80,11 @@
>>> > {
>>> > enum { NEWSH, LOADENTRY, EDITENTRY, NEWPW, NEWEXP } op;
>>> > struct passwd lpw, *old_pw, *pw;
>>> > - int ch, pfd, tfd;
>>> > + int ch, pfd, tfd, itr, auth;
>>> > const char *password;
>>> > char *arg = NULL;
>>> > uid_t uid;
>>> > + int max_retries = 3;
>>> > #ifdef YP
>>> > struct ypclnt *ypclnt;
>>> > const char *yp_domain = NULL, *yp_host = NULL;
>>> > @@ -227,9 +228,16 @@
>>> > }
>>> >
>>> > if (old_pw && !master_mode) {
>>> > - password = getpass("Password: ");
>>
>> I'm sure you have noticed the trailing space in the string.
>>
>>> > - if (strcmp(crypt(password, old_pw->pw_passwd),
>>> > - old_pw->pw_passwd) != 0)
>>> > + auth = 0;
>>> > + for(itr=0;itr>> > + password = getpass("Password:");
>>
>> The space's missing in this string. It might be better to stay
>> consistent with the original code.
>
> Good catch. No, I didn't notice the missing space the first time I read
> the diff :/
A better way to solve this may be to add an option to set the number
of retries before failure and then just pass it through to this
function.
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: NFS (& amd?) dysfunction descending a hierarchy
On Wed, Dec 10, 2008 at 07:06:20PM +0200, Kostik Belousov wrote:
> ...
> > What concerns me is that even if the attempted unmount gets EBUSY, the
> > user-level process descending the directory hierarchy is getting ENOENT
> > trying to issue fstatfs() against an open file descriptor.
> >
> > I'm having trouble figuring out any way that makes any sense.
>
> Basically, the problem is that NFS uses shared lookup, and this allows
> for the bug where several negative namecache entries are created for
> non-existent node. Then this node gets created, removing only the first
> negative namecache entry. For some reasons, vnode is reclaimed; amd'
> tasting of unmount is a good reason for vnode to be reclaimed.
>
> Now, you have existing path and a negative cache entry. This was
> reported by Peter Holm first, I listed relevant revisions that
> should fix this in previous mail.
Well, I messed up the machine I had been using for testing, and needed
to wait for IT to do something to it since I don't have physical or
console access to it.
So after I happened to demonstrate the effect using my desktop -- which
had been running RELENG_7_1, sources updated as of around 0400 hrs.
US/Pacific -- I decided to go ahead and update the desktop to RELENG_7_1
as of this morning (which had the commit to sys/kern/vfs_cache.c), then
test.
It still failed, apparently in the same way; details below.
First, here's a list of the files that were changed:
U lib/libarchive/archive_read_support_format_iso9660.c
U lib/libarchive/archive_string.c
U lib/libarchive/archive_string.h
U lib/libc/gen/times.3
U lib/libc/i386/sys/pipe.S
U lib/libc/i386/sys/reboot.S
U lib/libc/i386/sys/setlogin.S
U lib/libutil/Makefile
U lib/libutil/kinfo_getfile.c
U lib/libutil/kinfo_getvmmap.c
U lib/libutil/libutil.h
U share/man/man4/bce.4
U share/man/man5/Makefile
U share/man/man5/fstab.5
U share/man/man5/nullfs.5
U sys/amd64/Makefile
U sys/boot/forth/loader.conf.5
U sys/dev/ale/if_ale.c
U sys/dev/bce/if_bce.c
U sys/dev/cxgb/cxgb_main.c
U sys/dev/cxgb/common/cxgb_ael1002.c
U sys/dev/cxgb/common/cxgb_t3_hw.c
U sys/dev/cxgb/common/cxgb_xgmac.c
U sys/dev/re/if_re.c
U sys/fs/nullfs/null_vnops.c
U sys/kern/Make.tags.inc
U sys/kern/kern_descrip.c
U sys/kern/kern_proc.c
U sys/kern/vfs_cache.c
U sys/netinet/in_pcb.h
U sys/pci/if_rlreg.h
U sys/sys/sysctl.h
U sys/sys/user.h
U sys/ufs/ufs/ufs_quota.c
U usr.bin/procstat/Makefile
U usr.bin/procstat/procstat_files.c
U usr.bin/procstat/procstat_vm.c
U usr.bin/tar/util.c
U usr.bin/tar/test/Makefile
U usr.bin/tar/test/test_strip_components.c
U usr.bin/tar/test/test_symlink_dir.c
U usr.bin/xargs/xargs.1
U usr.sbin/mtree/mtree.c
We see that sys/kern/vfs_cache.c is, indeed, among them. And:
dwolf-bsd(7.1-P)[5] grep '\$FreeBSD' /sys/kern/vfs_cache.c
__FBSDID("$FreeBSD: src/sys/kern/vfs_cache.c,v 1.114.2.3 2008/12/09 16:20:58
kib Exp $");
dwolf-bsd(7.1-P)[6]
That should correspond to the desired version of the file.
Here we see an excerpt from the ktrace output for the amd(8) process and
its children; this is a point when amd(8) is trying an unmount() to see
if it can get away with it:
977 amd 1229033597.269612 CALL gettimeofday(0x807ad48,0)
977 amd 1229033597.269620 RET gettimeofday 0
977 amd 1229033597.269630 CALL
sigprocmask(SIG_BLOCK,0xbfbfeaec,0xbfbfeadc)
977 amd 1229033597.269637 RET sigprocmask 0
977 amd 1229033597.269645 CALL fork
977 amd 1229033597.273810 RET fork 1712/0x6b0
1712 amd 1229033597.273811 RET fork 0
977 amd 1229033597.273836 CALL sigprocmask(SIG_SETMASK,0xbfbfeadc,0)
1712 amd 1229033597.273845 CALL getpid
977 amd 1229033597.273850 RET sigprocmask 0
1712 amd 1229033597.273855 RET getpid 1712/0x6b0
977 amd 1229033597.273864 CALL gettimeofday(0x807ad48,0)
977 amd 1229033597.273874 RET gettimeofday 0
1712 amd 1229033597.273878 CALL unmount(0x2832c610,0)
...
1712 amd 1229033597.352643 RET unmount -1 errno 16 Device busy
1712 amd 1229033597.352695 CALL
sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfea0c)
1712 amd 1229033597.352728 RET sigprocmask 0
1712 amd 1229033597.352751 CALL sigprocmask(SIG_SETMASK,0x28097c10,0)
1712 amd 1229033597.352769 RET sigprocmask 0
1712 amd 1229033597.352781 CALL
sigprocmask(SIG_BLOCK,0x28097c00,0xbfbfe9dc)
1712 amd 1229033597.352790 RET sigprocmask 0
1712 amd 1229033597.352801 CALL sigprocmask(SIG_SETMASK,0x28097c10,0)
1712 amd 1229033597.352805 RET sigprocmask 0
1712 amd 1229033597.352815 CALL exit(0x10)
977 amd 1229033597.353085 RET select -1 errno 4 Interrupted system
call
977 amd 1229033597.353093 PSIG SIGCHLD caught handler=0x805de50
mask=0x0 code=0x0
977 amd 1229033597.353103 CALL wait4(0x,0xbfbfe83c,WNOHANG,0)
977 amd 1229033597.353116 RET wait4 1712/0x6b0
977 amd 1229033597.353122 CALL wait4(0x,0xb
