Re: md2 on current and 10.

2014-01-08 Thread Mikhail T.
On 08.01.2014 20:05, Peter Wemm wrote:
> The path of least resistance is to make a libmd2 port.  It's the only way I
> can see you getting to use it on 10.0.
*I* don't really care. *I* don't use md2 myself. I became aware of the problem
by accident -- because one of my ports was affected (tcl-trf). But I can fix the
port, no huhu.

It just seems to me, FreeBSD as a project goofed by abruptly removing the
functions, that have been in the base for many years. But if the src-committers
don't care to "ungoof" it -- despite my raising awareness as much (and, perhaps,
even above) as permissible by politeness -- then so be it...

Yours,

-mi

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


interesting routing bug...

2014-01-08 Thread John-Mark Gurney
Well, I was trying to manually add a route for a host on the local
network (I can explain why, but it doesn't matter) and I got this:
# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
default192.168.0.14   UGS   re0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0
# route add -host 192.168.0.254 -interface re0 -link 04:4a:31:d3:95:dc
add net 192.168.0.254: gateway re0
# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
0.0.0.0&0x2050090:2b:34:ab:bb:85  USre0
default192.168.0.14   UGS   re0
10.0.0.0/8 link#2 Umsk0
10.42.42.21link#2 UHS   lo0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0
# route delete 0.0.0.0
delete net 0.0.0.0
# route flush
::   localhost-fib 0   done
:::0.0.0.0   localhost-fib 0   done
fe80::   localhost-fib 0   done
ff02::   localhost-fib 0   done
# netstat -rnfinet
Routing tables

Internet:
DestinationGatewayFlagsNetif Expire
0.0.0.0&0x2050090:2b:34:ab:bb:85  USre0
127.0.0.1  link#3 UHlo0
192.168.0.0/24 link#1 U re0
192.168.0.21   link#1 UHS   lo0

So, as you can see, I have managed to add a bogus route w/o a way
to remove it short of rebooting the box...  And because of this route,
some hosts like svn0.us-west.freebsd.org will match causing the machine
to try to find the ip on the local network.

This route I assume should be rejected by the kernel and not added,
or there is a mismatch between the route program and how the kernel
understands it.

I can provide more information upon request.

Thanks.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: md2 on current and 10.

2014-01-08 Thread Glen Barber
On Wed, Jan 08, 2014 at 05:05:51PM -0800, Peter Wemm wrote:
> On 1/8/14, 7:00 AM, Mikhail T wrote:
> > On 08.01.2014 02:54, Peter Wemm wrote:
> >>> > Could we, please, have MD2 resurrected before 10.0 is officially out?
> >>> > Preferably in both -lmd and -lcrypto, but certainly in the former. Thank
> >>> > you! Yours,
> >> The time to bring this up was before the freeze for 10.0, a good 6+
> >> months ago. It is way too late now.
> > First of all, Peter, are you talking as a core-member, or expressing
> > personal opinion? In any case, I'd say it is not entirely fair to blame me
> > for reporting a problem "late" -- without any apologies about causing it in
> > the first place...
> > 
> > But is it really "too late" to add such a small piece back to where it was?
> > I'm not talking about resurrecting uucp here... Meanwhile, any existing
> > MD2-using application will simply break after upgrade -- does that not
> > bother anyone? If the code was removed after 19 years in the tree, is 6
> > months really "too late" to resurrect it?
> 
> Personal unless stated otherwise.
> 
> By "too late" I mean the cutoff has already passed for the final RC and
> there won't be more unless there's an absolute emergency.
> 
> As for timeliness of the request, here's the original commit:
> 
> r234746 | obrien | 2012-04-27 19:48:51 -0700 (Fri, 27 Apr 2012) | 10 lines
> 
> Remove the RFC 1319 MD2 Message-Digest Algorithm routines from libmd.
> 
> 1. The licensing terms for the MD2 routines from RFC is not under a BSD-like
>license.  Instead it is only granted for non-commercial Internet
>Privacy-Enhanced Mail.
> 2. MD2 is quite deprecated as it is no longer considered a cryptographically
>strong algorithm.
> 
> Discussed with: so (cperciva), core
> 
> 
> The original feature cutoff schedules were:
> 
>  head/ slush:   August 24, 2013
>  head/ freeze:  September 7, 2013
> 
> 10.0 is already late.  The original plan would have had 10.0 released in
> November.  That's before the first email in this thread - December.
> 
> You can always ask the release engineers for an exception, but given that
> the release is already overdue I'd bet money you won't get a positive
> reception to a request to a delay for md2.
> 

This is correct.

> You could ask obrien to revert his commit for head but I'd bet you won't
> get a positive response there.
> 
> >> However.. the code in libmd had had a non-commercial use restriction..
> >> Even if it wasn't too late, that code won't be back.
> > That restriction was not (enough of) a problem for 20 years (since 1994) --
> > and still is not in 9.x and 8.x. But, Ok...
> >> Your best bet is to create a crypto/libmd2 port.  Start with the code
> >> from openssl.
> > Adding such a port increases the number of hoops for any user to jump
> > through -- and the maintenance costs. Whereas the cost of simply adjusting
> > the base OpenSSL's configuration to include MD2 functionality is virtually
> > zero -- a single additional file file will be back (md2.h), and no new
> > libraries...
> 
> The path of least resistance is to make a libmd2 port.  It's the only way I
> can see you getting to use it on 10.0.
> 

This is also correct.

Glen



pgpUsPiVZDrei.pgp
Description: PGP signature


Re: md2 on current and 10.

2014-01-08 Thread Peter Wemm
On 1/8/14, 7:00 AM, Mikhail T wrote:
> On 08.01.2014 02:54, Peter Wemm wrote:
>>> > Could we, please, have MD2 resurrected before 10.0 is officially out?
>>> > Preferably in both -lmd and -lcrypto, but certainly in the former. Thank
>>> > you! Yours,
>> The time to bring this up was before the freeze for 10.0, a good 6+
>> months ago. It is way too late now.
> First of all, Peter, are you talking as a core-member, or expressing
> personal opinion? In any case, I'd say it is not entirely fair to blame me
> for reporting a problem "late" -- without any apologies about causing it in
> the first place...
> 
> But is it really "too late" to add such a small piece back to where it was?
> I'm not talking about resurrecting uucp here... Meanwhile, any existing
> MD2-using application will simply break after upgrade -- does that not
> bother anyone? If the code was removed after 19 years in the tree, is 6
> months really "too late" to resurrect it?

Personal unless stated otherwise.

By "too late" I mean the cutoff has already passed for the final RC and
there won't be more unless there's an absolute emergency.

As for timeliness of the request, here's the original commit:

r234746 | obrien | 2012-04-27 19:48:51 -0700 (Fri, 27 Apr 2012) | 10 lines

Remove the RFC 1319 MD2 Message-Digest Algorithm routines from libmd.

1. The licensing terms for the MD2 routines from RFC is not under a BSD-like
   license.  Instead it is only granted for non-commercial Internet
   Privacy-Enhanced Mail.
2. MD2 is quite deprecated as it is no longer considered a cryptographically
   strong algorithm.

Discussed with: so (cperciva), core


The original feature cutoff schedules were:

 head/ slush:   August 24, 2013
 head/ freeze:  September 7, 2013

10.0 is already late.  The original plan would have had 10.0 released in
November.  That's before the first email in this thread - December.

You can always ask the release engineers for an exception, but given that
the release is already overdue I'd bet money you won't get a positive
reception to a request to a delay for md2.

You could ask obrien to revert his commit for head but I'd bet you won't
get a positive response there.

>> However.. the code in libmd had had a non-commercial use restriction..
>> Even if it wasn't too late, that code won't be back.
> That restriction was not (enough of) a problem for 20 years (since 1994) --
> and still is not in 9.x and 8.x. But, Ok...
>> Your best bet is to create a crypto/libmd2 port.  Start with the code
>> from openssl.
> Adding such a port increases the number of hoops for any user to jump
> through -- and the maintenance costs. Whereas the cost of simply adjusting
> the base OpenSSL's configuration to include MD2 functionality is virtually
> zero -- a single additional file file will be back (md2.h), and no new
> libraries...

The path of least resistance is to make a libmd2 port.  It's the only way I
can see you getting to use it on 10.0.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' just won\342\200\231t do.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[head tinderbox] failure on amd64/amd64

2014-01-08 Thread FreeBSD Tinderbox
TB --- 2014-01-08 17:20:21 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-01-08 17:20:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-01-08 17:20:21 - starting HEAD tinderbox run for amd64/amd64
TB --- 2014-01-08 17:20:21 - cleaning the object tree
TB --- 2014-01-08 17:27:32 - /usr/local/bin/svn stat /src
TB --- 2014-01-08 17:27:35 - At svn revision 260453
TB --- 2014-01-08 17:27:36 - building world
TB --- 2014-01-08 17:27:36 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 17:27:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 17:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 17:27:36 - SRCCONF=/dev/null
TB --- 2014-01-08 17:27:36 - TARGET=amd64
TB --- 2014-01-08 17:27:36 - TARGET_ARCH=amd64
TB --- 2014-01-08 17:27:36 - TZ=UTC
TB --- 2014-01-08 17:27:36 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 17:27:36 - cd /src
TB --- 2014-01-08 17:27:36 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Wed Jan  8 17:27:43 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Wed Jan  8 21:12:57 UTC 2014
TB --- 2014-01-08 21:12:57 - generating LINT kernel config
TB --- 2014-01-08 21:12:57 - cd /src/sys/amd64/conf
TB --- 2014-01-08 21:12:57 - /usr/bin/make -B LINT
TB --- 2014-01-08 21:12:57 - cd /src/sys/amd64/conf
TB --- 2014-01-08 21:12:57 - /usr/sbin/config -m LINT
TB --- 2014-01-08 21:12:57 - building LINT kernel
TB --- 2014-01-08 21:12:57 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 21:12:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 21:12:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 21:12:57 - SRCCONF=/dev/null
TB --- 2014-01-08 21:12:57 - TARGET=amd64
TB --- 2014-01-08 21:12:57 - TARGET_ARCH=amd64
TB --- 2014-01-08 21:12:57 - TZ=UTC
TB --- 2014-01-08 21:12:57 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 21:12:57 - cd /src
TB --- 2014-01-08 21:12:57 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Jan  8 21:12:57 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Wed Jan  8 21:47:03 UTC 2014
TB --- 2014-01-08 21:47:03 - cd /src/sys/amd64/conf
TB --- 2014-01-08 21:47:03 - /usr/sbin/config -m LINT-NOINET
TB --- 2014-01-08 21:47:03 - building LINT-NOINET kernel
TB --- 2014-01-08 21:47:03 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 21:47:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 21:47:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 21:47:03 - SRCCONF=/dev/null
TB --- 2014-01-08 21:47:03 - TARGET=amd64
TB --- 2014-01-08 21:47:03 - TARGET_ARCH=amd64
TB --- 2014-01-08 21:47:03 - TZ=UTC
TB --- 2014-01-08 21:47:03 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 21:47:03 - cd /src
TB --- 2014-01-08 21:47:03 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Wed Jan  8 21:47:03 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Wed Jan  8 22:18:39 UTC 2014
TB --- 2014-01-08 22:18:39 - cd /src/sys/amd64/conf
TB --- 2014-01-08 22:18:39 - /usr/sbin/config -m LINT-NOINET6
TB --- 2014-01-08 22:18:39 - building LINT-NOINET6 kernel
TB --- 2014-01-08 22:18:39 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 22:18:39 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 22:18:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 22:18:39 - SRCCONF=/dev/null
TB --- 2014-01-08 22:18:39 - TARGET=amd64
TB --- 2014-01-08 22:18:39 - TARGET_ARCH=amd64
TB --- 2014-01-08 22:18:39 - TZ=UTC
TB --- 2014-01-08 22:18:39 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 22:18:39 - cd /src
TB --- 2014-01-08 22:18:39 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Wed Jan  8 22:18:39 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Wed Jan  8 22:50:06 UTC 2014
TB --- 2014-01-08 22:50:06 - cd /src/sys/amd64/conf
TB --- 2014-01-08 22:50:06 - /usr/sbin/confi

[head tinderbox] failure on i386/i386

2014-01-08 Thread FreeBSD Tinderbox
TB --- 2014-01-08 17:20:21 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-01-08 17:20:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-01-08 17:20:21 - starting HEAD tinderbox run for i386/i386
TB --- 2014-01-08 17:20:21 - cleaning the object tree
TB --- 2014-01-08 17:27:03 - /usr/local/bin/svn stat /src
TB --- 2014-01-08 17:27:06 - At svn revision 260453
TB --- 2014-01-08 17:27:07 - building world
TB --- 2014-01-08 17:27:07 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 17:27:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 17:27:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 17:27:07 - SRCCONF=/dev/null
TB --- 2014-01-08 17:27:07 - TARGET=i386
TB --- 2014-01-08 17:27:07 - TARGET_ARCH=i386
TB --- 2014-01-08 17:27:07 - TZ=UTC
TB --- 2014-01-08 17:27:07 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 17:27:07 - cd /src
TB --- 2014-01-08 17:27:07 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Wed Jan  8 17:27:14 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Jan  8 20:37:45 UTC 2014
TB --- 2014-01-08 20:37:45 - generating LINT kernel config
TB --- 2014-01-08 20:37:45 - cd /src/sys/i386/conf
TB --- 2014-01-08 20:37:45 - /usr/bin/make -B LINT
TB --- 2014-01-08 20:37:45 - cd /src/sys/i386/conf
TB --- 2014-01-08 20:37:45 - /usr/sbin/config -m LINT
TB --- 2014-01-08 20:37:45 - building LINT kernel
TB --- 2014-01-08 20:37:45 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 20:37:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 20:37:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 20:37:45 - SRCCONF=/dev/null
TB --- 2014-01-08 20:37:45 - TARGET=i386
TB --- 2014-01-08 20:37:45 - TARGET_ARCH=i386
TB --- 2014-01-08 20:37:45 - TZ=UTC
TB --- 2014-01-08 20:37:45 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 20:37:45 - cd /src
TB --- 2014-01-08 20:37:45 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Jan  8 20:37:45 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Wed Jan  8 21:15:11 UTC 2014
TB --- 2014-01-08 21:15:11 - cd /src/sys/i386/conf
TB --- 2014-01-08 21:15:11 - /usr/sbin/config -m LINT-NOINET
TB --- 2014-01-08 21:15:11 - building LINT-NOINET kernel
TB --- 2014-01-08 21:15:11 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 21:15:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 21:15:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 21:15:11 - SRCCONF=/dev/null
TB --- 2014-01-08 21:15:11 - TARGET=i386
TB --- 2014-01-08 21:15:11 - TARGET_ARCH=i386
TB --- 2014-01-08 21:15:11 - TZ=UTC
TB --- 2014-01-08 21:15:11 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 21:15:11 - cd /src
TB --- 2014-01-08 21:15:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Wed Jan  8 21:15:12 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Wed Jan  8 21:47:16 UTC 2014
TB --- 2014-01-08 21:47:16 - cd /src/sys/i386/conf
TB --- 2014-01-08 21:47:16 - /usr/sbin/config -m LINT-NOINET6
TB --- 2014-01-08 21:47:17 - building LINT-NOINET6 kernel
TB --- 2014-01-08 21:47:17 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 21:47:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 21:47:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 21:47:17 - SRCCONF=/dev/null
TB --- 2014-01-08 21:47:17 - TARGET=i386
TB --- 2014-01-08 21:47:17 - TARGET_ARCH=i386
TB --- 2014-01-08 21:47:17 - TZ=UTC
TB --- 2014-01-08 21:47:17 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 21:47:17 - cd /src
TB --- 2014-01-08 21:47:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Wed Jan  8 21:47:17 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Wed Jan  8 22:19:46 UTC 2014
TB --- 2014-01-08 22:19:46 - cd /src/sys/i386/conf
TB --- 2014-01-08 22:19:46 - /usr/sbin/config -m LINT-NOIP
TB --- 2014-01-08 22:19:46 - building LINT-NOI

Re: [CFT] bsdinstall and zfsboot enhancements

2014-01-08 Thread Jilles Tjoelker
On Sun, Jan 05, 2014 at 04:04:03PM -0500, Nathan Whitehorn wrote:
> On 12/01/13 07:34, Jilles Tjoelker wrote:
> > On Sat, Nov 30, 2013 at 04:36:18PM -0600, Nathan Whitehorn wrote:
> >> This took much longer than I'd anticipated, but the patch to init is
> >> attached. I chose not to make the changes to init rather than
> >> getttyent() and friends in libc, which I am open to revisiting.
> > lib/libpam/modules/pam_securetty/pam_securetty.c calls getttynam(3) and
> > will not allow root login on a "fake" TTY that getttynam() does not
> > know. This module is enabled by default for the "login" service.

> > So it is probably better to patch libc rather than init.

> OK, here's a revised patch. This one is shorter and works by introducing
> an "auto" flag (ideas for names appreciated) that means "on" if the line
> is an active console and "off" otherwise. Note that the behavior is now:
> - ttys marked "off" stay off
> - ttys marked "on" stay on
> - ttys marked "auto" are enabled iff they are console devices
> - ttys not present in /etc/ttys stay off

> This behavior change is much easier to implement when doing it in libc
> for various structural reasons and allows the terminal type, etc. to be
> specified in the usual way.

Instead of "auto" you could use "ifconsole".

This looks sensible to me.

> > As a preparatory patch, you could remove se_index and session_index from
> > init. They are only used to warn about a changed slot number in utmp(5)
> > which is irrelevant with utmpx. This noise warning would also appear
> > in most cases when changing from a "fake" console entry to a real line
> > in /etc/ttys. Also, if you do decide to fake ttys entries in init rather
> > than libc, the patch to init will be simpler.

> With the new patch, this is indeed the case: no changes to init are
> necessary at all. This does not change any behavior unless explicitly
> requested in /etc/ttys, so unless there are any objections in the next
> couple days, I will commit it.

I have some small remarks inline below.

I would like to remove se_index and session_index from init soon if it
does not conflict with other work.

> Index: include/ttyent.h
> ===
> --- include/ttyent.h  (revision 260331)
> +++ include/ttyent.h  (working copy)
> @@ -37,6 +37,7 @@
>  
>  #define  _TTYS_OFF   "off"
>  #define  _TTYS_ON"on"
> +#define  _TTYS_AUTO  "auto"
>  #define  _TTYS_SECURE"secure"
>  #define  _TTYS_INSECURE  "insecure"
>  #define  _TTYS_WINDOW"window"
> Index: lib/libc/gen/getttyent.c
> ===
> --- lib/libc/gen/getttyent.c  (revision 260331)
> +++ lib/libc/gen/getttyent.c  (working copy)
> @@ -39,6 +39,9 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  static char zapchar;
>  static FILE *tf;
>  static size_t lbsize;
> @@ -64,6 +67,32 @@
>   return (t);
>  }
>  
> +static int
> +auto_tty_status(const char *ty_name)
> +{
> + size_t len;
> + char *buf, *cons, *nextcons;
> +
> + /* Check if this is an enabled kernel console line */
> + buf = NULL;
> + if (sysctlbyname("kern.console", NULL, &len, NULL, 0) == -1)
> + return (0); /* Errors mean don't enable */
> + buf = malloc(len);
> + if (sysctlbyname("kern.console", buf, &len, NULL, 0) == -1)
> + return (0);

conscontrol also does this, but is it possible that the length increases
between the checks?

> +
> + if ((cons = strchr(buf, '/')) == NULL)
> + return (0);
> + *cons = '\0';
> + nextcons = buf;
> + while ((cons = strsep(&nextcons, ",")) != NULL && strlen(cons) != 0) {
> + if (strcmp(cons, ty_name) == 0)
> + return (TTY_ON);
> + }
> +
> + return (0);
> +}
> +
>  struct ttyent *
>  getttyent(void)
>  {
> @@ -126,6 +155,8 @@
>   tty.ty_status &= ~TTY_ON;
>   else if (scmp(_TTYS_ON))
>   tty.ty_status |= TTY_ON;
> + else if (scmp(_TTYS_AUTO))
> + tty.ty_status |= auto_tty_status(tty.ty_name);
>   else if (scmp(_TTYS_SECURE))
>   tty.ty_status |= TTY_SECURE;
>   else if (scmp(_TTYS_INSECURE))
> Index: libexec/getty/ttys.5
> ===
> --- libexec/getty/ttys.5  (revision 260331)
> +++ libexec/getty/ttys.5  (working copy)
> @@ -102,8 +102,11 @@
>  .Pp
>  As flag values, the strings ``on'' and ``off'' specify that
>  .Xr init 8
> -should (should not) execute the command given in the second field,
> -while ``secure'' (if ``on'' is also specified) allows users with a
> +should (should not) execute the command given in the second field.
> +``auto'' will cause this line to be enabled if and only if it is
> +an active kernel console device (it is equivalent to ``on'' in this
> +case).
> +The 

Re: Supermicro X10SLH-F motherboard kernel panics with 9.2 Release and 10.0 RC4

2014-01-08 Thread Dan Sency


On 1/7/2014 6:26 PM, Allan Jude wrote:

On 2014-01-07 15:05, Dan Sency wrote:

Hello Everyone,

I need help resolving kernel panics on a Supermicro X10SLH-F
motherboard in a Supermicro SC-825 chassis.  I originally installed
FreeBSD 9.2 Release/amd64 but kept having kernel panics after varying
amounts of uptime and while running the following command against some
or all of the SATA hard drives in the system:

dd if=/dev/zero of=/dev/ada/n/ bs=100m &

A sample vmcore file is here:

http://codepad.org/FIjqh2Nt

While canvassing the FreeBSD Forums I followed a suggestion to try
10.0 RC4/amd64.  The machine still panicked under the same conditions
at around 27 hours uptime.  The vmcore file is here:

http://codepad.org/svtRfRT1

System memory has run Memtest for 62 hours and 47 passes without error
and the chassis has dual 740W PSU's so I think I have memory and PSU
possibilities eliminated.

Apologies if I've sent my plea to the wrong place.  Tell me where to
go and I'll bother someone else.  Thanks, Dan.



How is your swap configured on this machine?


I have a 4G swap partition on the drive containing FreeBSD.

--
The only person who always got his work done by Friday was Robinson Crusoe.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: md2 on current and 10.

2014-01-08 Thread Mikhail T
On 08.01.2014 02:54, Peter Wemm wrote:
>> > Could we, please, have MD2 resurrected before 10.0 is officially out?
>> > Preferably in both -lmd and -lcrypto, but certainly in the former. Thank
>> > you! Yours,
> The time to bring this up was before the freeze for 10.0, a good 6+
> months ago. It is way too late now.
First of all, Peter, are you talking as a core-member, or expressing
personal opinion? In any case, I'd say it is not entirely fair to blame
me for reporting a problem "late" -- without any apologies about causing
it in the first place...

But is it really "too late" to add such a small piece back to where it
was? I'm not talking about resurrecting uucp here... Meanwhile, any
existing MD2-using application will simply break after upgrade -- does
that not bother anyone? If the code was removed after 19 years in the
tree, is 6 months really "too late" to resurrect it?
> However.. the code in libmd had had a non-commercial use restriction..
> Even if it wasn't too late, that code won't be back.
That restriction was not (enough of) a problem for 20 years (since 1994)
-- and still is not in 9.x and 8.x. But, Ok...
> Your best bet is to create a crypto/libmd2 port.  Start with the code
> from openssl.
Adding such a port increases the number of hoops for any user to jump
through -- and the maintenance costs. Whereas the cost of simply
adjusting the base OpenSSL's configuration to include MD2 functionality
is virtually zero -- a single additional file file will be back (md2.h),
and no new libraries...

OpenSSL port offers MD2 as an option -- surely the base version can have
that same option flipped on without breaking anything.

Yours,

-mi

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[head tinderbox] failure on amd64/amd64

2014-01-08 Thread FreeBSD Tinderbox
TB --- 2014-01-08 05:30:19 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-01-08 05:30:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-01-08 05:30:19 - starting HEAD tinderbox run for amd64/amd64
TB --- 2014-01-08 05:30:19 - cleaning the object tree
TB --- 2014-01-08 05:39:53 - /usr/local/bin/svn stat /src
TB --- 2014-01-08 05:39:56 - At svn revision 260441
TB --- 2014-01-08 05:39:57 - building world
TB --- 2014-01-08 05:39:57 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 05:39:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 05:39:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 05:39:57 - SRCCONF=/dev/null
TB --- 2014-01-08 05:39:57 - TARGET=amd64
TB --- 2014-01-08 05:39:57 - TARGET_ARCH=amd64
TB --- 2014-01-08 05:39:57 - TZ=UTC
TB --- 2014-01-08 05:39:57 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 05:39:57 - cd /src
TB --- 2014-01-08 05:39:57 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Wed Jan  8 05:40:04 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Wed Jan  8 09:31:26 UTC 2014
TB --- 2014-01-08 09:31:26 - generating LINT kernel config
TB --- 2014-01-08 09:31:26 - cd /src/sys/amd64/conf
TB --- 2014-01-08 09:31:26 - /usr/bin/make -B LINT
TB --- 2014-01-08 09:31:26 - cd /src/sys/amd64/conf
TB --- 2014-01-08 09:31:26 - /usr/sbin/config -m LINT
TB --- 2014-01-08 09:31:26 - building LINT kernel
TB --- 2014-01-08 09:31:26 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 09:31:26 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 09:31:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 09:31:26 - SRCCONF=/dev/null
TB --- 2014-01-08 09:31:26 - TARGET=amd64
TB --- 2014-01-08 09:31:26 - TARGET_ARCH=amd64
TB --- 2014-01-08 09:31:26 - TZ=UTC
TB --- 2014-01-08 09:31:26 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 09:31:26 - cd /src
TB --- 2014-01-08 09:31:26 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Jan  8 09:31:26 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Wed Jan  8 10:05:57 UTC 2014
TB --- 2014-01-08 10:05:57 - cd /src/sys/amd64/conf
TB --- 2014-01-08 10:05:57 - /usr/sbin/config -m LINT-NOINET
TB --- 2014-01-08 10:05:57 - building LINT-NOINET kernel
TB --- 2014-01-08 10:05:57 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 10:05:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 10:05:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 10:05:57 - SRCCONF=/dev/null
TB --- 2014-01-08 10:05:57 - TARGET=amd64
TB --- 2014-01-08 10:05:57 - TARGET_ARCH=amd64
TB --- 2014-01-08 10:05:57 - TZ=UTC
TB --- 2014-01-08 10:05:57 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 10:05:57 - cd /src
TB --- 2014-01-08 10:05:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Wed Jan  8 10:05:57 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Wed Jan  8 10:36:28 UTC 2014
TB --- 2014-01-08 10:36:28 - cd /src/sys/amd64/conf
TB --- 2014-01-08 10:36:28 - /usr/sbin/config -m LINT-NOINET6
TB --- 2014-01-08 10:36:29 - building LINT-NOINET6 kernel
TB --- 2014-01-08 10:36:29 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 10:36:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 10:36:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 10:36:29 - SRCCONF=/dev/null
TB --- 2014-01-08 10:36:29 - TARGET=amd64
TB --- 2014-01-08 10:36:29 - TARGET_ARCH=amd64
TB --- 2014-01-08 10:36:29 - TZ=UTC
TB --- 2014-01-08 10:36:29 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 10:36:29 - cd /src
TB --- 2014-01-08 10:36:29 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Wed Jan  8 10:36:29 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Wed Jan  8 11:07:54 UTC 2014
TB --- 2014-01-08 11:07:54 - cd /src/sys/amd64/conf
TB --- 2014-01-08 11:07:54 - /usr/sbin/confi

[head tinderbox] failure on i386/i386

2014-01-08 Thread FreeBSD Tinderbox
TB --- 2014-01-08 05:30:19 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2014-01-08 05:30:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2014-01-08 05:30:19 - starting HEAD tinderbox run for i386/i386
TB --- 2014-01-08 05:30:19 - cleaning the object tree
TB --- 2014-01-08 05:39:33 - /usr/local/bin/svn stat /src
TB --- 2014-01-08 05:39:37 - At svn revision 260441
TB --- 2014-01-08 05:39:38 - building world
TB --- 2014-01-08 05:39:38 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 05:39:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 05:39:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 05:39:38 - SRCCONF=/dev/null
TB --- 2014-01-08 05:39:38 - TARGET=i386
TB --- 2014-01-08 05:39:38 - TARGET_ARCH=i386
TB --- 2014-01-08 05:39:38 - TZ=UTC
TB --- 2014-01-08 05:39:38 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 05:39:38 - cd /src
TB --- 2014-01-08 05:39:38 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Wed Jan  8 05:39:45 UTC 2014
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Jan  8 08:56:19 UTC 2014
TB --- 2014-01-08 08:56:19 - generating LINT kernel config
TB --- 2014-01-08 08:56:19 - cd /src/sys/i386/conf
TB --- 2014-01-08 08:56:19 - /usr/bin/make -B LINT
TB --- 2014-01-08 08:56:19 - cd /src/sys/i386/conf
TB --- 2014-01-08 08:56:19 - /usr/sbin/config -m LINT
TB --- 2014-01-08 08:56:20 - building LINT kernel
TB --- 2014-01-08 08:56:20 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 08:56:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 08:56:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 08:56:20 - SRCCONF=/dev/null
TB --- 2014-01-08 08:56:20 - TARGET=i386
TB --- 2014-01-08 08:56:20 - TARGET_ARCH=i386
TB --- 2014-01-08 08:56:20 - TZ=UTC
TB --- 2014-01-08 08:56:20 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 08:56:20 - cd /src
TB --- 2014-01-08 08:56:20 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Jan  8 08:56:20 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Wed Jan  8 09:33:48 UTC 2014
TB --- 2014-01-08 09:33:48 - cd /src/sys/i386/conf
TB --- 2014-01-08 09:33:48 - /usr/sbin/config -m LINT-NOINET
TB --- 2014-01-08 09:33:48 - building LINT-NOINET kernel
TB --- 2014-01-08 09:33:48 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 09:33:48 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 09:33:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 09:33:48 - SRCCONF=/dev/null
TB --- 2014-01-08 09:33:48 - TARGET=i386
TB --- 2014-01-08 09:33:48 - TARGET_ARCH=i386
TB --- 2014-01-08 09:33:48 - TZ=UTC
TB --- 2014-01-08 09:33:48 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 09:33:48 - cd /src
TB --- 2014-01-08 09:33:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Wed Jan  8 09:33:48 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Wed Jan  8 10:06:23 UTC 2014
TB --- 2014-01-08 10:06:23 - cd /src/sys/i386/conf
TB --- 2014-01-08 10:06:23 - /usr/sbin/config -m LINT-NOINET6
TB --- 2014-01-08 10:06:23 - building LINT-NOINET6 kernel
TB --- 2014-01-08 10:06:23 - CROSS_BUILD_TESTING=YES
TB --- 2014-01-08 10:06:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2014-01-08 10:06:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2014-01-08 10:06:23 - SRCCONF=/dev/null
TB --- 2014-01-08 10:06:23 - TARGET=i386
TB --- 2014-01-08 10:06:23 - TARGET_ARCH=i386
TB --- 2014-01-08 10:06:23 - TZ=UTC
TB --- 2014-01-08 10:06:23 - __MAKE_CONF=/dev/null
TB --- 2014-01-08 10:06:23 - cd /src
TB --- 2014-01-08 10:06:23 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Wed Jan  8 10:06:23 UTC 2014
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Wed Jan  8 10:38:18 UTC 2014
TB --- 2014-01-08 10:38:18 - cd /src/sys/i386/conf
TB --- 2014-01-08 10:38:18 - /usr/sbin/config -m LINT-NOIP
TB --- 2014-01-08 10:38:18 - building LINT-NOI

Re: Call for FreeBSD 2013Q4 (October-December) Status Reports

2014-01-08 Thread Gabor Pali
Dear FreeBSD Community,

Please note that the submission date for the October to December
Quarterly Status Reports is January 14th, 2014, a little less than one
week away.  Please consult my earlier message for the details:

On Sat, Dec 14, 2013 at 2:05 PM, Gabor Pali  wrote:
> They do not have to be very long -- basically they may be about
> anything that lets people know what is going on around the FreeBSD
> Project.  Submission of reports is not restricted to committers:
> Anyone who is doing anything interesting and FreeBSD-related can (and
> therefore encouraged to) write one!
>
> The preferred and easiest submission method is to use the XML
> generator [1] with the result emailed as an attachment to us, that is,
> mont...@freebsd.org [2].  There is also an XML template [3] which can
> be filled out manually and attached if preferred.  For the expected
> content and style, please study our guidelines on how to write a good
> status reports [4].
>
> To enable compilation and publication of the Q4 report as soon as
> possible for the January 14th deadline, please be prompt with any
> report submissions you may have.
>
> We are looking forward to all of your 2013Q4 reports!
>
> Thanks,
> Gabor
>
>
> [1] http://www.freebsd.org/cgi/monthly.cgi
> [2] mailto:mont...@freebsd.org
> [3] http://www.freebsd.org/news/status/report-sample.xml
> [4] http://www.freebsd.org/news/status/howto.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"