RE: Re: Why won't 8.2 umount -f?

2012-02-13 Thread Devin Teske
>  Original Message  
> Subject: Re: Why won't 8.2 umount -f?
> Date: Mon, 13 Feb 2012 13:20:55 -0800
> From: Doug Barton 
> Organization: http://SupersetSolutions.com/
> To: 
> CC: 
> 
Cross posting? (gasp!)

> On 02/13/2012 13:02, Doug Barton wrote:
> > Is there some magic I'm missing to convince an 8.2 system to umount -f?
> > I had an NFS server crash, so I'm trying to get the mounts updated. All
> > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly
> > 8.2-pN) are just hanging forever.
> 
> ... and it gets worse. I just 'shutdown -r now'ed one of my
> less-critical 8.2 systems, and it hung for several minutes after "All
> buffers synced." After a power cycle it came back, but the buffers
> weren't actually synced because it's still fsck'ing some pretty large
> file systems.
> 
> What the heck?

We've noticed this behavior too (on 8.1-RELEASE-p6).

The work-around (to avoid long fsck) is to:

1. Drop to the kernel debugger (Ctrl+Alt+ESC -- requires DDB to be enabled in
kernel)

2. Type: call boot(0)

This causes the system to attempt a second sync of the buffers. This second
attempt ends up timing out but succeeds in resetting the CPU (after 3x 60s
timeouts).

The price (waiting 180s before cpu_reset() is called) can be well worth it
(avoiding multi-hour fsck) because the disks will be marked clean.

For us, this is a serious issue and like Doug, we too exclaim "what the heck?"
Shouldn't have to drop to kernel debugger and [redundantly] invoke boot(0) after
syncer's hang just prior to cpu_reset().
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


RE: New BSD Installer

2012-02-14 Thread Devin Teske


> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Ian Smith
> Sent: Tuesday, February 14, 2012 9:15 AM
> To: Bruce Cran
> Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov
> Subject: Re: New BSD Installer
> 
> On Sun, 12 Feb 2012 15:32:51 +, Bruce Cran wrote:
>  > On 2/10/2012 7:47 PM, Alex Samorukov wrote:
>  > > I am highly against reverting. Old installer is not GPT aware and in fact
>  > > is unmaintained for a very long time.
>  >
>  > That's not really correct: quite a lot of work was done on it last year.
> 
> Indeed.  Was it you working on the updated sade(8) adding GPT and ZFS?
> 
> 
> 
> I don't see it in terms of reverting.  Much other useful functionality
> of sysinstall has yet to be reimplemented.

Ron McDowell and I are working feverishly on bsdconfig(8) set to arrive in
10.0-CURRENT

Highlights:
- It's modular
- It's easily estendable/maintained (written in sh(1))
- It's goal is to completely reimplement all missing functionality from
sysinstall(8)

However, it's still in the preliminary stages.

Discussions on bsdconfig are being held on -sysinstall@

Development work is being performed off the reservation (using SourceForge CVS
server) until we can agree on the structure prior to import to the base of HEAD
SVN tree.

Despite being preliminary code, there is currently 8529 lines of code so far.

I won't be posting links to the preliminary code (it's still preliminary) for
fear of getting too much feedback too early in the game (but if you're
interested, you can crawl the recent posts to -sysinstall@ and gleen the links
both from Ron and myself).


>  Sure, I know, send code ..
> but it's not only the functionality lost, but the ability for new users
> to accomplish a good deal of initial server setup before they're skilled
> enough to do it all from the command line, which is where I was in '98.
> 

bsdconfig(8) will fill this gap as sysinstall(8) did in the past.

The current plan moving forward is:

1. RELENG_9 will continue to offer both sysinstall and bsdinstall in the
installed base

2. RELENG_10 will drop sysinstall(8) but bring in bsdconfig(8)

This much has been agreed upon in the discussions involving many.


> I also think much of the sometimes gratuitous deprecation of sysinstall
> is unwarranted.

Yes, it has been acknowledged by many that the scheduled deprecation is
aggressive.


>  I've used sysinstall post-installation regularly since
> '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2.  Since one
> small disaster on 3.3 about 12 years ago (installing to the wrong slice)
> I've had no major issues with it, mostly partitioning all sorts of disks
> but also browsing and adding useful packages at installation.
> 

When bsdconfig(8) reaches a usable state (is entered into HEAD), we encourage
you to be an avid tester in the early stages to make sure we "get it right" with
respect to replication of sysinstall(8) features.

bsdconfig(8) should work fine on RELENG_9 just as 10.0-CURRENT


> Strangely, the big push to GPT partitions was oft said to be because MBR
> slices provided too few partitions. 

That's part of it (no pun intended).

The other big deal is that you can't exceed 2TB on a single primary partition.


> I never found 4 * 6 much of a limit
> myself, and now the default install makes a Linux-like single partition,
> rendering dump & restore more or less unusable or at least impractical,

I'm with you on this one. I really don't like the single-"/" setup.


> while booting multiple systems on GPT also seems to require Linux tools.
> 
> I don't know whether this move away from BSD traditional filesystem
> partitioning (/, /var, /usr etc) to Linux-style came down from Core On
> High or is just the prerogative of installer-writers?  Jordan was both
> the latter and a big part of the former for many years, but I guess
> that's something that can be reverted if people feel to do so.
> 

Maybe a vote should be taken. There's about 12 votes in this office here alone
for putting the partition scheme back the way it was (Colin Percival had a great
formula for determining partition sizes).


> I expect most developers run mostly the latest gear, and nowadays tend
> to use vbox images a good deal, but there will be many laptops and other
> systems using MBR slices and bsdlabel partitions for years to come, and
> I'd hate to see FreeBSD's longterm support for _slightly_ older hardware
> disappear, just because of having added better support for latest kit.
> 

Others will point out that if you try hard enough, you can create the old-style
MBR partitions with RELENG_9 (note: some minor bugs were documented in
9.0-RELEASE; the next release will not suffer these fallbacks).


> I for one will be screwed if sade, fdisk and bsdlabel disappear, as the
> release notes for 9 seem to indicate may be imminently on the cards.
> 

I too would be sad if those disappear. However, I do think

RE: New BSD Installer

2012-02-14 Thread Devin Teske


> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Lars Engels
> Sent: Tuesday, February 14, 2012 9:28 AM
> To: Ian Smith
> Cc: Bruce Cran; Alex Samorukov; Joe Holden; FreeBSD Stable Mailing List
> Subject: Re: New BSD Installer
> 
> On Wed, Feb 15, 2012 at 04:15:17AM +1100, Ian Smith wrote:
> > On Sun, 12 Feb 2012 15:32:51 +, Bruce Cran wrote:
> >  > On 2/10/2012 7:47 PM, Alex Samorukov wrote:
> >  > > I am highly against reverting. Old installer is not GPT aware and in 
> > fact
> >  > > is unmaintained for a very long time.
> >  >
> >  > That's not really correct: quite a lot of work was done on it last year.
> >
> > Indeed.  Was it you working on the updated sade(8) adding GPT and ZFS?
> >
> > 
> >
> > I don't see it in terms of reverting.  Much other useful functionality
> > of sysinstall has yet to be reimplemented.
> 
> What exactly are you missing?
> There's sysutils/host-setup to configure your system like sysinstall
> did.

sysutils/host-setup (written/maintained by me) is only good for the following 
bits right now:

1. Time zone
2. Hostname/Domain
3. Network Interfaces
4. Default Router/Gateway
5. DNS nameservers

There's still quite a bit more that sysinstall(8) offered which isn't provided 
by anything yet (sysutils/host-setup included).


> There's sade and I am working on a tool to browse and add packages from
> the installation media and / or the ftp mirrors.

Ron McDowell and I are working on a new tool named "bsdconfig(8)" which is very 
modular and written in sh(1).

bsdconfig(8) is designed squarely at reimplementing all of the sysinstall(8) 
post-install bits so that we can cleanly whack sysinstall(8) without the prior 
complaints.

The portion of bsdconfig(8) that will handle browsing and adding of packages 
from either the installation media or ftp mirrors is incomplete at the moment, 
and we'd love it if you were willing to either:

(a) download the preliminary framework for bsdconfig(8) and start working on 
the packages module, or

(b) join the SourceForge CVS project and start working on bsdconfig(8) in 
realtime with Ron and I

NOTE: Choice of either option will result in further information being 
disbursed for your digestive pleasure.

So far, bsdconfig(8) has the 8529 lines of code (counting all modules, 
internationalization files, and Makefiles) with the following 
modules/components (status listed for each):

1. Distributions
Description: Install additional distribution sets
Status: pending development

2. Documentation installation
Description: Install FreeBSD Documentation set
Status: Done. Links to "bsdinstall docsinstall"

3. Packages
Description: Install Pre-packaged Software
Status: pending development

4. Password
Description: Set Root Password
Status: pending development

5. Fdisk
Description: Fdisk Partition Editor
Status: pending development
Note: Could be linked directly to sade(8)

6. Disklabel
Description: Disk Label Editor
Status: pending development
Note: Could be linked directly to sade(8)

7. Login/Group Management
Description: Add user's login and group information
    Status: Done (by Ron McDowell)

8. Console
Description: Console Settings
Status: pending development

9. Timezone
Description: Set up Time Zone
Status: Done (by Devin Teske; me)

NOTE: Functionality shamelessly ripped from my ports addition: sysutils/tzdialog

10. Media Selection
Description: Select Media to Install From
Status: pending development

11. Mouse
Description: Configure the Mouse
Status: pending development

12. Networking Management
Description: Setup Networking interfaces, services, etc.
Status: Done (by Devin Teske; me)

NOTE: Functionality shamelessly ripped from my ports addition: 
sysutils/host-setup

13. Security
Description: Set Security Parameters
Status: pending development

14. Startup
Description: Set Startup Parameters
Status: pending development

15. Ttys
Description: Configure Ttys
Status: pending development

I am currently working on the framework some more and then I'm going to jump 
over to working on #14 "Startup".

As you can see from the above-list, we have quite a bit of functionality to 
migrate from sysinstall(8) over to bsdconfig(8) -- however the most difficult 
bits (user management, network management, and timezone have all been done so 
the rest should fall like a house of cards -- especially since we have really 
nice modular includes making the modules nice and light-weight).
-- 
Devin


__

RE: New BSD Installer

2012-02-14 Thread Devin Teske


> -Original Message-
> From: Kevin Oberman [mailto:kob6...@gmail.com]
> Sent: Tuesday, February 14, 2012 11:51 AM
> To: Devin Teske
> Cc: Ian Smith; Bruce Cran; Alex Samorukov; Joe Holden; FreeBSD Stable Mailing
> List
> Subject: Re: New BSD Installer
> 
> On Tue, Feb 14, 2012 at 9:43 AM, Devin Teske 
> wrote:
> >
> >
> >> -Original Message-
> >> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> >> sta...@freebsd.org] On Behalf Of Ian Smith
> >> Sent: Tuesday, February 14, 2012 9:15 AM
> >> To: Bruce Cran
> >> Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov
> >> Subject: Re: New BSD Installer
> >>
> >> Strangely, the big push to GPT partitions was oft said to be because MBR
> >> slices provided too few partitions.
> >
> > That's part of it (no pun intended).
> >
> > The other big deal is that you can't exceed 2TB on a single primary
partition.
> >
> >
> >> I never found 4 * 6 much of a limit
> >> myself, and now the default install makes a Linux-like single partition,
> >> rendering dump & restore more or less unusable or at least impractical,
> >
> > I'm with you on this one. I really don't like the single-"/" setup.
> >
> >
> >> while booting multiple systems on GPT also seems to require Linux tools.
> >>
> >> I don't know whether this move away from BSD traditional filesystem
> >> partitioning (/, /var, /usr etc) to Linux-style came down from Core On
> >> High or is just the prerogative of installer-writers?  Jordan was both
> >> the latter and a big part of the former for many years, but I guess
> >> that's something that can be reverted if people feel to do so.
> >>
> >
> > Maybe a vote should be taken. There's about 12 votes in this office here
alone
> > for putting the partition scheme back the way it was (Colin Percival had a
great
> > formula for determining partition sizes).
> 
> I suggest that both be implemented, which looks to the untrained eye
> as a straight-forward thing to implement, and then the install ask if
> a single partition or a traditional multi-partition system should be
> installed. I prefer multi and use that on all of my systems.
> 
> I also really prefer GPT for a variety of reasons, but we need better
> tools to support things. I miss booteasy. Yes, you can get it to boot
> from a different partition, but it is a pain. I deal with it by
> putting FreeBSD on one disk and Windows on another when I want a
> dual-boot system. I put the MBR formatted (Windows) is first in the
> boot order, so I can just hit F5 to boot the FreeBSD disk.
> 
> This works for me, but I suspect that lots of people would prefer
> having multiple OSes on a single disk...especially when it's a single
> spindle laptop. (I suspect laptops are more commonly dual-boot than
> most any other platform.)
> 
> As for fdisk and bsdlabel, I'm happy to see both go. They have a
> horrid user interface and require a calculator to get right. Yes, I
> use them, but only because there is no other way to do some things.
> (sade(8) comes closer all of the time, though.)

Please don't get rid of fdisk or bsdlabel as they are (and forever will be)
required to do things like:

1. scripted formatting of a thumb drive

2. automated probing of disk information (fdisk -p)

3. Other tasks that are not suitably handled by curses-based utilities

For example, the following command will create a second Windows partition on a
thumb drive without user interaction:

echo "p 2 0x0c * *" | fdisk -f - /dev/da0

If you take away fdisk, how am I supposed to achieve the above?
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


RE: Why won't 8.2 umount -f?

2012-02-14 Thread Devin Teske


> -Original Message-
> From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org]
> On Behalf Of Doug Barton
> Sent: Tuesday, February 14, 2012 1:05 PM
> To: Rick Macklem
> Cc: freebsd...@freebsd.org; freebsd-stable@FreeBSD.org
> Subject: Re: Why won't 8.2 umount -f?
> 
> On 02/14/2012 08:39, Rick Macklem wrote:
> > I took a look and they seem to have been MFC'd.
> 
> That's awesome! Thanks for your time on this. I guess we've got some
> upgrading to do.
> 

+1

Awaiting 8.3 with bated breath!
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


RE: New BSD Installer

2012-02-14 Thread Devin Teske


> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Mike Andrews
> Sent: Tuesday, February 14, 2012 1:11 PM
> To: freebsd-stable@freebsd.org
> Subject: Re: New BSD Installer
> 
> On 2/14/2012 3:05 PM, Devin Teske wrote:
> > Please don't get rid of fdisk or bsdlabel as they are (and forever will be)
> > required to do things like:
> >
> > 1. scripted formatting of a thumb drive
> >
> > 2. automated probing of disk information (fdisk -p)
> >
> > 3. Other tasks that are not suitably handled by curses-based utilities
> >
> > For example, the following command will create a second Windows partition on
> a
> > thumb drive without user interaction:
> >
> > echo "p 2 0x0c * *" | fdisk -f - /dev/da0
> >
> > If you take away fdisk, how am I supposed to achieve the above?
> 
> /sbin/gpart add -t 12 -i 2 da0
> 

I stand corrected.

Ok, remove at-will but not before 10.0 please. Looking for 9.x to be the
transitional phase.
-- 
Devin


_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


RE: libarchive and WITHOUT_CRYPT

2012-03-15 Thread Devin Teske


> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Oliver Lehmann
> Sent: Thursday, March 15, 2012 11:19 AM
> To: sta...@freebsd.org
> Cc: kient...@freebsd.org
> Subject: libarchive and WITHOUT_CRYPT
> 
> Hi,
> 
> has someone ever tested to compile world with WITHOUT_CRYPT set
> in /etc/src.conf? It stops at:
> 
> In file included from
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_support
_f
> ormat_xar.c:57:
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:129:2
0:
> error: sha1.h: No such file or
> directory
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:166:2
0:
> error: sha2.h: No such file or
> directory
> In file included from
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_write_set_fo
rm
> at_mtree.c:42:
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:129:2
0:
> error: sha1.h: No such file or
> directory
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:166:2
0:
> error: sha2.h: No such file or
> directory
> mkdep: compile failed
> 
> So it obviously does not work correctly :(
> 

I've already filed a PR against this:

http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/164206

There's a patch in the PR that fixes this.

BTW, the PR is still open after 59 days (can someone have a look?)!
-- 
Devin


_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


RE: libarchive and WITHOUT_CRYPT

2012-03-15 Thread Devin Teske


> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Devin Teske
> Sent: Thursday, March 15, 2012 11:42 AM
> To: 'Oliver Lehmann'; sta...@freebsd.org
> Cc: kient...@freebsd.org
> Subject: RE: libarchive and WITHOUT_CRYPT
> 
> 
> 
> > -Original Message-
> > From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> > sta...@freebsd.org] On Behalf Of Oliver Lehmann
> > Sent: Thursday, March 15, 2012 11:19 AM
> > To: sta...@freebsd.org
> > Cc: kient...@freebsd.org
> > Subject: libarchive and WITHOUT_CRYPT
> >
> > Hi,
> >
> > has someone ever tested to compile world with WITHOUT_CRYPT set
> > in /etc/src.conf? It stops at:
> >
> > In file included from
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_support
> _f
> > ormat_xar.c:57:
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:129:2
> 0:
> > error: sha1.h: No such file or
> > directory
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:166:2
> 0:
> > error: sha2.h: No such file or
> > directory
> > In file included from
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_write_set_fo
> rm
> > at_mtree.c:42:
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:129:2
> 0:
> > error: sha1.h: No such file or
> > directory
> >
>
/usr/src/lib/libarchive/../../contrib/libarchive/libarchive/archive_hash.h:166:2
> 0:
> > error: sha2.h: No such file or
> > directory
> > mkdep: compile failed
> >
> > So it obviously does not work correctly :(
> >
> 
> I've already filed a PR against this:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/164206
> 
> There's a patch in the PR that fixes this.
> 
> BTW, the PR is still open after 59 days (can someone have a look?)!
> --
> Devin
> 

There appears to be a duplicate (and much older) PR that is related:

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160922

NOTE: I haven't tested that patch. It may not work. I know that misc/164206
works to fix RELENG_9 however.

But let me warn you...

If you're compiling RELENG_9, after you fix the error in libarchive, you'll then
hit 3 more errors (of which I have filed PRs for also):

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164208
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164209
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164210

If you apply the patches in misc/164206, kern/164208, kern/164209, and
kern/164210...

You should be able to compile RELENG_9 cleanly all-the-way through with
-DWITHOUT_OPENSSL (comparable to -DWITHOUT_CRYPT).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


[PATCHES] make buildworld -DWITHOUT_OPENSSL

2012-03-15 Thread Devin Teske
Hi All,

I wanted to ping someone to see about getting some PR's looked at.

I have four PR's that are each 59-days old today and I don't want them to be
forgotten.

The following four PR's contain patches to fix/address multiple compilation
issues when using "WITHOUT_OPENSSL" in RELENG_9.

http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/164206
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164208
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164209
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/164210

Thanks in advance,
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


[CFT] Need Testers for: sysutils/bsdconfig

2012-06-21 Thread Devin Teske
Hi everybody,

I've published a new port (sysutils/bsdconfig) so that we can get some testing 
on the replacement for sysinstall's [post-installation] "Configure" menu.

We're on a tight schedule, so if you have the time and/or energy your timely 
efforts will be GREATLY appreciated in helping to get this software tested 
prior to the 9.1-R code freeze.

Please welcome "bsdconfig" (port pkg-descr below):

bsdconfig is a robust utility for configuring/managing various aspects of the
FreeBSD Operating System. Feature-highlights include (but are not limited to):
  - Modular, stable, efficient and i18n-compatible.
  - Easily maintained/extendable sh(1) source/syntax.
  - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog).
  - rc.conf(5) configuration/management based on sysutils/sysrc
  - Timezone configuration based on sysutils/tzdialog
  - Networking management based on sysutils/host-setup

WWW: http://druidbsd.sourceforge.net/

Again, thank you very much for testing this new software.
-- 
Devin

P.S. Due to the large codebase comprising bsdconfig, ample precautions should 
be taken. I've not noticed any negative behavior in months of usage, but just 
be warned.

P.P.S. I don't think on subscribed to -stable@, so include me in your replies.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-21 Thread Devin Teske
Sorry, forgot to mention…

The port will only install/work on 9.0 or higher.

Testing needed on FreeBSD 9.0-R (or higher) and/or PC-BSD 9.0-R (or higher).
-- 
Devin


On Jun 21, 2012, at 3:32 PM, Devin Teske wrote:

> Hi everybody,
> 
> I've published a new port (sysutils/bsdconfig) so that we can get some 
> testing on the replacement for sysinstall's [post-installation] "Configure" 
> menu.
> 
> We're on a tight schedule, so if you have the time and/or energy your timely 
> efforts will be GREATLY appreciated in helping to get this software tested 
> prior to the 9.1-R code freeze.
> 
> Please welcome "bsdconfig" (port pkg-descr below):
> 
> bsdconfig is a robust utility for configuring/managing various aspects of the
> FreeBSD Operating System. Feature-highlights include (but are not limited to):
>  - Modular, stable, efficient and i18n-compatible.
>  - Easily maintained/extendable sh(1) source/syntax.
>  - Works with both dialog(1) in base and Xdialog(1) from ports (x11/xdialog).
>  - rc.conf(5) configuration/management based on sysutils/sysrc
>  - Timezone configuration based on sysutils/tzdialog
>  - Networking management based on sysutils/host-setup
> 
> WWW: http://druidbsd.sourceforge.net/
> 
> Again, thank you very much for testing this new software.
> -- 
> Devin
> 
> P.S. Due to the large codebase comprising bsdconfig, ample precautions should 
> be taken. I've not noticed any negative behavior in months of usage, but just 
> be warned.
> 
> P.P.S. I don't think on subscribed to -stable@, so include me in your replies.
> 
> _
> The information contained in this message is proprietary and/or confidential. 
> If you are not the intended recipient, please: (i) delete the message and all 
> copies; (ii) do not disclose, distribute or use the message in any manner; 
> and (iii) notify the sender immediately. In addition, please be aware that 
> any message addressed to our domain is subject to archiving and review by 
> persons other than the intended recipient. Thank you.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-22 Thread Devin Teske

On Jun 22, 2012, at 12:07 AM, Eugene Grosbein wrote:

> 22.06.2012 10:50, Ron McDowell пишет:
> 
>>> Again, thank you very much for testing this new software.
>>> P.S. Due to the large codebase comprising bsdconfig, ample precautions 
>>> should be taken. I've not noticed any negative behavior in months of usage, 
>>> but just be warned.
>>> 
>>> P.P.S. I don't think on subscribed to -stable@, so include me in your 
>>> replies.
>> I'm one of the coauthors of this code, and I am here on -stable.  As 
>> stated, this port will only run on 9.0-RELEASE and later.
>> 
>> Please give it a try!  Thanks!
> 
> I've tried it on installed 9.0-STABLE system.

First, thank you for testing!


> 1. At the moment, the documentation does not install:
> 
> Could not install package en-freebsd-doc (pkg_add: unable to fetch
> 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/en-freebsd-doc.tbz'
> by URL)
> 

Ok. Thx.

A PR should be filed against bsdinstall (since bsdconfig is simply linking to 
"bsdinstall docsinstall" for that menu item and is not actually responsible for 
the bug).


> 2. For system running single gmirror gm0 consisting of 2 whole disks
> ada0 and ada1, 'Label allocated disk partitions' offers
> only ada0 and ada1 for disklabel editor and not gm0.
> And disklabel editor shows empty list of partitions.
> 

Ok, Thx.

This too is not part of bsdconfig, but is linked to sade(8).

NOTE: "Documentation Installation" and "Disk Partition/Label" are the only two 
modules that are pointed to other tools (the former linked to "bsdinstall 
docsinstall" and the latter linked to "sade").

The goal for this is to replace sade (which is not geom compatible) with a new 
tool.

This is on the community's to-do list.


> 3. Similar for FDISK Partition Editor (ada0/ada1 and not gm0 for choise),
> but Partition Editor presents whole disk space as 'unused'
> 
> Note that current SATA disk prices and quality offers no choice for servers
> other that some kind of RAID.
> 

Again, this is because sade(8) is not geom compatible.


> 4. Networking Devices configuration presents lagg0 device as  interface type>.
> It should provide descriptive string like 'Link aggregation/failover'.
> 

It's on my to-do list to change the way descriptions are calculated.

Currently, I've got a static hard-coded list of descriptions. Someone 
recommended that there was a way to get this information from sysctl.


> 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network 
> interface'.
> It should work same way for vlan1-vlan4095 interfaces at least.
> 

I'd like to know if the sysctl MIB's for describing network interfaces is 
reliable. Maybe I'll keep the static list as a fallback. But yes, you're 
absolutely right -- I should have supported up to 5 digits even (ifconfig has 
internal limits of 16-bit unsigned integer for the interface instance-number).


> 6. Same for ipfw0 pseudo-interface.
> 

Curious what sysctl says about it.


> 7. Networking Devices configuration does not allow to configure any interface
> while there are mounted NFS volumes. Should present a warning only, not 
> disallow the operation.

Did I completely disallow it? I'll have to re-check -- I thought that I had 
made it so that you could view/edit the configuration but that the warning says 
that changes will not become effective until you either reboot or visit the 
menu again when no NFS mounts are active.


> For example, it should be possible to configure new vlan interface while NFS 
> mount
> uses another clan.
> 

Do you know of a handy way of determining which NFS mount is using which 
network interface? And further, is there a handy way of traversing the route 
path to determine that one interface isn't required as an intermediary transit 
device? (meaning: can one truly ever know that making a new configuration 
active on any interface could not potentially drop your entire machine from the 
net with hung NFS mounts?)

Many months of testing in the lab produced no less than 6 edge-cases where -- 
if a network link or route is modified when NFS mounts are active -- the 
machine can enter an unstable/unusable state.

So we decided to err on the side of caution when it came to allowing settings 
to be made-active when NFS mounts are active.

I'm not against improving the code, but I'm wondering if it wouldn't be safer 
to stick to disallowing any/all changes from being made-active (while allowing 
viewing/editing without making-active) when NFS mounts are active.

NOTE: There are other safe-guards too. For example, if you're logged in via SSH 
and using X11 forwarding while passing the "-X" flag (to use Xdialog(1)), you 
are disallowed from making a new hostname active (you can change the hostname, 
but not make it active) because that would cause the very next iteration of 
Xdialog(1) to fail due to a surreptitious X authority revocation based on the 
hostname-change in mid-session.


> 8. In DNS Nameserver Configuration, it's n

Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-22 Thread Devin Teske

On Jun 22, 2012, at 12:53 AM, Eugene Grosbein wrote:

> 22.06.2012 14:37, Devin Teske пишет:
> 
>>> 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network 
>>> interface'.
>>> It should work same way for vlan1-vlan4095 interfaces at least.
>>> 
>> 
>> I'd like to know if the sysctl MIB's for describing network interfaces is 
>> reliable. Maybe I'll keep the static list as a fallback. But yes, you're 
>> absolutely right -- I should have supported up to 5 digits even (ifconfig 
>> has internal limits of 16-bit unsigned integer for the interface 
>> instance-number).
>> 
>> 
>>> 6. Same for ipfw0 pseudo-interface.
>>> 
>> 
>> Curious what sysctl says about it.
> 
> I do not know what sysctl subtree do you refer to.
> 

If you're using em(4) device, try:

sysctl dev.em.0.%desc

Otherwise (for example), if using fxp(4), try:

sysctl dev.fxp.0.%desc

Or for your vlan:

sysctl dev.vlan.16.%desc

And try for your ipfw(4) interface:

sysctl dev.ipfw.0.%desc

Are each of those meaningful?

NOTE: They aren't available unless you have the hardware -- so I can't (for 
example) try "sysctl dev.fxp.0.%desc" unless I have an fxp0 device displayed in 
ifconfig(8).



>>> 7. Networking Devices configuration does not allow to configure any 
>>> interface
>>> while there are mounted NFS volumes. Should present a warning only, not 
>>> disallow the operation.
>> 
>> Did I completely disallow it?
> 
> Yes.
> 
>> I'll have to re-check -- I thought that I had made it so that you could 
>> view/edit the configuration but that the warning says that changes will not 
>> become effective until you either reboot or visit the menu again when no NFS 
>> mounts are active.
>> 
>> 
>>> For example, it should be possible to configure new vlan interface while 
>>> NFS mount
>>> uses another clan.
>>> 
>> 
>> Do you know of a handy way of determining which NFS mount is using which 
>> network interface? And further, is there a handy way of traversing the route 
>> path to determine that one interface isn't required as an intermediary 
>> transit device? (meaning: can one truly ever know that making a new 
>> configuration active on any interface could not potentially drop your entire 
>> machine from the net with hung NFS mounts?)
>> 
>> Many months of testing in the lab produced no less than 6 edge-cases where 
>> -- if a network link or route is modified when NFS mounts are active -- the 
>> machine can enter an unstable/unusable state.
>> 
>> So we decided to err on the side of caution when it came to allowing 
>> settings to be made-active when NFS mounts are active.
>> 
>> I'm not against improving the code, but I'm wondering if it wouldn't be 
>> safer to stick to disallowing any/all changes from being made-active (while 
>> allowing viewing/editing without making-active) when NFS mounts are active.
>> 
>> NOTE: There are other safe-guards too. For example, if you're logged in via 
>> SSH and using X11 forwarding while passing the "-X" flag (to use 
>> Xdialog(1)), you are disallowed from making a new hostname active (you can 
>> change the hostname, but not make it active) because that would cause the 
>> very next iteration of Xdialog(1) to fail due to a surreptitious X authority 
>> revocation based on the hostname-change in mid-session.
> 
> I'm sure that bsdconfig should emit warnings only but not disallow root to 
> make any needed changes.

I'm inclined to agree. FreeBSD should not prevent you from being stupid (as 
someone once told me). I should change the errors to warnings and allow the 
user to [potentially] hose their connection given ample 
warning/chance-to-back-out.


> NFS may use completly unrelated routes/interfaces, X11 may be user over 
> network without ssh -X etc.

Got that one covered actually -- you can tell when a user is using X11 
forwarding versus X11 local.


> It's pretty annoying for administrator to fight with tools thinking they know 
> better  what root should do.
> 
>>> 8. In DNS Nameserver Configuration, it's not clear that one, in fact,
>>> can remove unneeded DNS server through two-step procedure - first try to 
>>> edit,
>>> then clear the address. It should be more obvious at first.
>>> 
>> 
>> Can you have a look at "bsdconfig startup_rcconf" and see if that's a better 
>> way to go about the deletion-process?
>> 
>> Or perhaps you're just adv

Re: [wifi] wifimgr for freebsd

2012-06-22 Thread Devin Teske

On Jun 22, 2012, at 1:32 PM, Adrian Chadd wrote:

> Hi!
> 
> On 18 June 2012 03:43, freegih  wrote:
>> Hi, I made a wifi script based on  the wlanconfig in bsdinstaller.
>> here is the code:
>> https://github.com/gihnius/freebsd-wifi
>> 
>> I think we can make it more suitable for many devices and normal use.
>> 
>> Any idea to write a normal feature script to use freebsd wifi easily ?
>> 
>> and thanks to the author of wlanconfig.
> 
> I'd love to see a non-ridiculous command line toolkit (which could
> later be extended to be GUI) for FreeBSD wireless.
> 

I think bsdconfig is the right landing zone for this (once it's tested -- check 
out the port sysutils/bsdconfig -- and committed).

bsdconfig is:
(a) scriptable
(b) pluggable
(c) modular
(d) Supports both Command-line (dialog) and GUI (Xdialog)
(e) is i18n-compatible
(f) written in sh(1) with very clean code that is properly scoped and consistent
-- 
Devin


> I suggest canvasing the freebsd forums and speak to whoever pipes up
> with some ideas. That crowd is very likely the right target for this
> kind of work. :)
> 
> Good luck!
> 
> 
> adrian
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-22 Thread Devin Teske

On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:

> 
> When selecting user account expiry the calendar starts at 1 January 1970. I
> understand that this is when Unix time started but it would be nice for it
> to start from the current date.
> 

This was on-purpose because there is a discrepancy in passwd(5) manual 
regarding what a value of zero (0) means for these fields.

>From passwd(5):

 The change field is the number of seconds from the epoch, UTC, until the
 password for the account must be changed.  This field may be left empty
 to turn off the password aging feature.

Nowhere in the manual does it say that zero is a synonym to being left empty.

So I can think of one of two solutions:

Update the manual to say that "0" is the same as being "left empty"

or

Change the behavior to treat zero as "[zero] seconds from the epoch".

Currently, bsdconfig treats zero as the latter, not the former -- until such 
discrepancy can be resolved.

NOTE: It should also be noted that Linux and FreeBSD when pointed at the same 
LDAP server have disagreements between the value of this field and the best 
solution in this situation is to remove the field in question (e.g., 
shadowExpire, shadowMax, etc.).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-22 Thread Devin Teske

On Jun 22, 2012, at 3:32 PM, Devin Teske wrote:

> 
> On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:
> 
>> 
>> When selecting user account expiry the calendar starts at 1 January 1970. I
>> understand that this is when Unix time started but it would be nice for it
>> to start from the current date.
>> 
> 
> This was on-purpose because there is a discrepancy in passwd(5) manual 
> regarding what a value of zero (0) means for these fields.
> 
> From passwd(5):
> 
>  The change field is the number of seconds from the epoch, UTC, until the
>  password for the account must be changed.  This field may be left empty
>  to turn off the password aging feature.
> 
> Nowhere in the manual does it say that zero is a synonym to being left empty.
> 

And yet, this is how the system treats zero (was my complaint).

The user root (and toor, and several other system users) come with a default 
value of zero for this field.

If zero was treated according to the manual, then root would be disabled by 
default. But that's clearly not the case in a default installation which has a 
value of zero.

So, when you're using bsdconfig to view an existing user that has a value of 
zero, you will notice that the default calendar date/time that is chosen 
corresponds to "zero seconds from the epoch, UTC", despite the fact that I know 
(and you know) that zero is synonymous with NULL.

So I'm a fan of updating the man page and when that is done, I am happy to 
change bsdconfig to treat zero as-such. But right now I wanted to stay true to 
the manual (which plainly states that any non-NULL value is treated as seconds 
from the epoch).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-23 Thread Devin Teske

On Jun 22, 2012, at 3:44 PM, Devin Teske wrote:

> 
> On Jun 22, 2012, at 3:32 PM, Devin Teske wrote:
> 
>> 
>> On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:
>> 
>>> 
>>> When selecting user account expiry the calendar starts at 1 January 1970. I
>>> understand that this is when Unix time started but it would be nice for it
>>> to start from the current date.
>>> 
>> 
>> This was on-purpose because there is a discrepancy in passwd(5) manual 
>> regarding what a value of zero (0) means for these fields.
>> 
>> From passwd(5):
>> 
>>  The change field is the number of seconds from the epoch, UTC, until the
>>  password for the account must be changed.  This field may be left empty
>>  to turn off the password aging feature.
>> 
>> Nowhere in the manual does it say that zero is a synonym to being left empty.
>> 
> 
> And yet, this is how the system treats zero (was my complaint).
> 
> The user root (and toor, and several other system users) come with a default 
> value of zero for this field.
> 
> If zero was treated according to the manual, then root would be disabled by 
> default. But that's clearly not the case in a default installation which has 
> a value of zero.
> 
> So, when you're using bsdconfig to view an existing user that has a value of 
> zero, you will notice that the default calendar date/time that is chosen 
> corresponds to "zero seconds from the epoch, UTC", despite the fact that I 
> know (and you know) that zero is synonymous with NULL.
> 
> So I'm a fan of updating the man page and when that is done, I am happy to 
> change bsdconfig to treat zero as-such. But right now I wanted to stay true 
> to the manual (which plainly states that any non-NULL value is treated as 
> seconds from the epoch).

In an effort to get the passwd(5) manual updated (pre-requisite to fixing the 
bsdconfig(8) functionality to coincide with the manual change), I've filed PR 
ports/169354.

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=169354
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-23 Thread Devin Teske

On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:

>> 5. Same for vlan16. For vlan9 is shows right 'IEEE 802.1Q VLAN network
>> interface'.
>> It should work same way for vlan1-vlan4095 interfaces at least.
>> 
> 
> I'd like to know if the sysctl MIB's for describing network interfaces
> is reliable. Maybe I'll keep the static list as a fallback. But yes, 
> you're
> absolutely right -- I should have supported up to 5 digits even (ifconfig
> has internal limits of 16-bit unsigned integer for the interface
> instance-number).

I've made the necessary changes to support vlan0-vlan9 (though the system 
will only support up to vlan65534).


>> 6. Same for ipfw0 pseudo-interface.
>> 
> 
> Curious what sysctl says about it.
 
 I do not know what sysctl subtree do you refer to.
 
>>> 
>>> If you're using em(4) device, try:
>>> 
>>> sysctl dev.em.0.%desc
>>> 
>>> Otherwise (for example), if using fxp(4), try:
>>> 
>>> sysctl dev.fxp.0.%desc
>>> 
>>> Or for your vlan:
>>> 
>>> sysctl dev.vlan.16.%desc
>>> 
>>> And try for your ipfw(4) interface:
>>> 
>>> sysctl dev.ipfw.0.%desc
>>> 
>>> Are each of those meaningful?
>>> 
>>> NOTE: They aren't available unless you have the hardware -- so I can't
>>> (for example) try "sysctl dev.fxp.0.%desc" unless I have an fxp0 device
>>> displayed in ifconfig(8).
> 
>> That's driver-dependent. For example, lagg does not presents %desc nor
>> ipfw0 and I suppose pretty many others do not. You could use %desc if it's
>> present and fall back to internal static list otherwise.
> 

Ok, I've added that functionality, but … since neither lagg(4) nor ipfw(4) 
provide %desc MIB, … what should we provide as static fallbacks?


> Just something cosmetic but when I add a user when it comes to select the
> shell it does not have a title like: Select a shell
> 

I fixed this too.


> Also it said that my user add failed but it was actually added as uid 1005.

I'm working on this one. I'm changing the routines to allow the UNIX pw(8) 
errors to filter through, rather than masking them with a static error on 
non-success.


> I added another user and it stated the uid 1005 when I was creating it but
> showed 1006 in the summary screen. It also said that adding the user failed.

"pw usernext" is executed to get the next uid/gid pair that is available. It's 
possible a user was added in the process. I've not witnessed this, but will try 
to replicate.


> Perhaps I used to short a password as there was no password field entered in
> /etc/master.passwd
> twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh
> test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh
> 

The password is only set (as a separate command) if the pw(8) useradd 
succeeded. I'm working on catching errors in edge-cases where we should proceed 
despite non-success.


> When selecting user account expiry the calendar starts at 1 January 1970. I
> understand that this is when Unix time started but it would be nice for it
> to start from the current date.
> 

I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the PR 
in a timely fashion, I'll pro-actively modify bsdconfig to follow what the 
man-page _should_ say versus what it _does_ say about "how to treat the value 
of zero" (the default).
-- 
Thanks for testing!,
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [CFT] Need Testers for: sysutils/bsdconfig

2012-06-26 Thread Devin Teske

On Jun 23, 2012, at 12:11 PM, Devin Teske wrote:

> 
> On Jun 22, 2012, at 5:27 AM, Clayton Milos wrote:
> 
[snip]

>> Also it said that my user add failed but it was actually added as uid 1005.
> 
> I'm working on this one. I'm changing the routines to allow the UNIX pw(8) 
> errors to filter through, rather than masking them with a static error on 
> non-success.
> 

I overhauled the usermgmt module to rely entirely on pw(8). It should work a 
lot better now. I addressed all concerns in the rewrite which should be 
published soon in the up-coming 0.7.3 PORTVERSION.


> 
>> I added another user and it stated the uid 1005 when I was creating it but
>> showed 1006 in the summary screen. It also said that adding the user failed.
> 
> "pw usernext" is executed to get the next uid/gid pair that is available. 
> It's possible a user was added in the process. I've not witnessed this, but 
> will try to replicate.
> 

This race-condition was addressed and should no longer be possible (regardless 
of whether it was the root cause of the failure to add).



> 
>> Perhaps I used to short a password as there was no password field entered in
>> /etc/master.passwd
>> twat:*:1005:1005::1340540161:1340626570:twat:/home/twat:/bin/sh
>> test1:*:1006:1006::1340454020:1340496000:test1:/home/test1:/bin/tcsh
>> 
> 
> The password is only set (as a separate command) if the pw(8) useradd 
> succeeded. I'm working on catching errors in edge-cases where we should 
> proceed despite non-success.
> 

This too has been enhanced.



> 
>> When selecting user account expiry the calendar starts at 1 January 1970. I
>> understand that this is when Unix time started but it would be nice for it
>> to start from the current date.
>> 
> 
> I filed PR docs/169354 against the passwd(5) manual. If nobody picks up the 
> PR in a timely fashion, I'll pro-actively modify bsdconfig to follow what the 
> man-page _should_ say versus what it _does_ say about "how to treat the value 
> of zero" (the default).

PR docs/169354 was closed after being patched by bjk@ (thx again bjk!)

The upcoming release folds this change in to coincide with the updated manual.
-- 
Thanks again for testing!
Devin

P.S. Keep an eye out for the next revision of this port for more testing.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: How to clean up /

2012-11-27 Thread Devin Teske
I'd delete (or move):

/boot/kernel.old1

And if you need more space:

/boot/kernel.old

I don't know about the following:

/compat/linux/usr/lib/locale/locale-archive.tmpl

As for the rest, leave it (note: /rescue/* are not really separate files but 
hard-links to /rescue/rescue).
-- 
Devin

On Nov 27, 2012, at 2:57 PM, Efraín Déctor wrote:

> Hello. 
> 
> I recently upgraded to 9.1-RC3, everything went fine, however the / partition 
> its about to get full. Im really new to FreeBSD so I don’t know what files 
> can be deleted safely.
> 
> # find -x / -size +1 -exec du -h {} \;
> 
> 16M/boot/kernel/kernel
> 60M/boot/kernel/kernel.symbols
> 6.7M/boot/kernel/if_ath.ko.symbols
> 6.4M/boot/kernel/vxge.ko.symbols
> 9.4M/boot/kernel/xfs.ko.symbols
> 15M/boot/kernel/zfs.ko.symbols
> 15M/boot/kernel.old/kernel
> 55M/boot/kernel.old/kernel.symbols
> 6.7M/boot/kernel.old/if_ath.ko.symbols
> 6.4M/boot/kernel.old/vxge.ko.symbols
> 9.2M/boot/kernel.old/xfs.ko.symbols
> 15M/boot/kernel.old/zfs.ko.symbols
> 15M/boot/kernel.old1/kernel
>  5M/rescue/rescue
>  5M/rescue/cat
>  5M/rescue/chflags
>  5M/rescue/chio
>  5M/rescue/chmod
>  5M/rescue/cp
>  5M/rescue/date
>  5M/rescue/dd
>  5M/rescue/df
>  5M/rescue/echo
>  5M/rescue/ed
>  5M/rescue/red
>  5M/rescue/expr
>  5M/rescue/getfacl
>  5M/rescue/hostname
>  5M/rescue/kenv
>  5M/rescue/kill
>  5M/rescue/ln
>  5M/rescue/link
>  5M/rescue/ls
>  5M/rescue/mkdir
>  5M/rescue/mv
>  5M/rescue/pkill
>  5M/rescue/pgrep
>  5M/rescue/ps
>  5M/rescue/pwd
>  5M/rescue/realpath
>  5M/rescue/rm
>  5M/rescue/unlink
>  5M/rescue/rmdir
>  5M/rescue/setfacl
>  5M/rescue/sh
>  5M/rescue/stty
>  5M/rescue/sync
>  5M/rescue/test
>  5M/rescue/[
>  5M/rescue/rcp
>  5M/rescue/csh
>  5M/rescue/tcsh
>  5M/rescue/atacontrol
>  5M/rescue/badsect
>  5M/rescue/camcontrol
>  5M/rescue/ccdconfig
>  5M/rescue/clri
>  5M/rescue/devfs
>  5M/rescue/dmesg
>  5M/rescue/dump
>  5M/rescue/rdump
>  5M/rescue/dumpfs
>  5M/rescue/dumpon
>  5M/rescue/fsck
>  5M/rescue/fsck_ffs
>  5M/rescue/fsck_4.2bsd
>  5M/rescue/fsck_ufs
>  5M/rescue/fsck_msdosfs
>  5M/rescue/fsdb
>  5M/rescue/fsirand
>  5M/rescue/gbde
>  5M/rescue/geom
>  5M/rescue/glabel
>  5M/rescue/gpart
>  5M/rescue/ifconfig
>  5M/rescue/init
>  5M/rescue/kldconfig
>  5M/rescue/kldload
>  5M/rescue/kldstat
>  5M/rescue/kldunload
>  5M/rescue/ldconfig
>  5M/rescue/md5
>  5M/rescue/mdconfig
>  5M/rescue/mdmfs
>  5M/rescue/mknod
>  5M/rescue/mount
>  5M/rescue/mount_cd9660
>  5M/rescue/mount_msdosfs
>  5M/rescue/mount_nfs
>  5M/rescue/mount_ntfs
>  5M/rescue/mount_nullfs
>  5M/rescue/mount_udf
>  5M/rescue/mount_unionfs
>  5M/rescue/newfs
>  5M/rescue/newfs_msdos
>  5M/rescue/nos-tun
>  5M/rescue/ping
>  5M/rescue/reboot
>  5M/rescue/fastboot
>  5M/rescue/halt
>  5M/rescue/fasthalt
>  5M/rescue/restore
>  5M/rescue/rrestore
>  5M/rescue/rcorder
>  5M/rescue/route
>  5M/rescue/routed
>  5M/rescue/rtquery
>  5M/rescue/rtsol
>  5M/rescue/savecore
>  5M/rescue/spppcontrol
>  5M/rescue/swapon
>  5M/rescue/sysctl
>  5M/rescue/tunefs
>  5M/rescue/umount
>  5M/rescue/atmconfig
>  5M/rescue/ping6
>  5M/rescue/ipf
>  5M/rescue/zfs
>  5M/rescue/zpool
>  5M/rescue/bsdlabel
>  5M/rescue/disklabel
>  5M/rescue/fdisk
>  5M/rescue/dhclient
>  5M/rescue/head
>  5M/rescue/mt
>  5M/rescue/sed
>  5M/rescue/tail
>  5M/rescue/tee
>  5M/rescue/gzip
>  5M/rescue/gunzip
>  5M/rescue/gzcat
>  5M/rescue/zcat
>  5M/rescue/bzip2
>  5M/rescue/bunzip2
>  5M/rescue/bzcat
>  5M/rescue/xz
>  5M/rescue/unxz
>  5M/rescue/lzma
>  5M/rescue/unlzma
>  5M/rescue/xzcat
>  5M/rescue/lzcat
>  5M/rescue/tar
>  5M/rescue/vi
>  5M/rescue/ex
>  5M/rescue/id
>  5M/rescue/groups
>  5M/rescue/whoami
>  5M/rescue/chroot
>  5M/rescue/chown
>  5M/rescue/chgrp
>  5M/rescue/nc
> 76M/compat/linux/usr/lib/locale/locale-archive.tmpl
> 8.0M/.sujournal
> 
> Thanks in advance.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that 

Re: Library Problem

2012-11-28 Thread Devin Teske

On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote:

> I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of them 
> worked just fine.  The last one is causing a problem.  It will not look in 
> /usr/local/lib/ for shared libraries.  I did the standard install, moved in 
> some source, compiled it and tried to run it.  The library is there.  On the 
> working systems ktrace shows:
> 
>  2259 introCALL  access(0x28066000,0)
>  2259 introNAMI  "/lib/libsermons.so"
>  2259 introRET   access -1 errno 2 No such file or directory
>  2259 introCALL  access(0x28066000,0)
>  2259 introNAMI  "/usr/lib/libsermons.so"
>  2259 introRET   access -1 errno 2 No such file or directory
>  2259 introCALL  access(0x28066000,0)
>  2259 introNAMI  "/usr/lib/compat/libsermons.so"
>  2259 introRET   access -1 errno 2 No such file or directory
>  2259 introCALL  access(0x28066000,0)
>  2259 introNAMI  "/usr/local/lib/libsermons.so"
>  2259 introRET   access 0
> 
> 
> On the failing system ktrace shows:
> 
>  6746 introNAMI  "/lib/libsermons.so"
>  6746 introRET   access -1 errno 2 No such file or directory
>  6746 introCALL  access(0x28066000,0)
>  6746 introNAMI  "/usr/lib/libsermons.so"
>  6746 introRET   access -1 errno 2 No such file or directory
>  6746 introCALL  access(0x28066000,0)
>  6746 introNAMI  "/usr/lib/compat/libsermons.so"
>  6746 introRET   access -1 errno 2 No such file or directory
>  6746 introCALL  access(0x28066000,0)
>  6746 introNAMI  "/lib/libsermons.so"
>  6746 introRET   access -1 errno 2 No such file or directory
>  6746 introCALL  access(0x28066000,0)
>  6746 introNAMI  "/usr/lib/libsermons.so"
>  6746 introRET   access -1 errno 2 No such file or directory
>  6746 introCALL  write(0x2,0x28060080,0x3c)
>  6746 introGIO   fd 2 wrote 60 bytes
>   "Shared object "libsermons.so" not found, required by "intro""
> 
> 
> It never attempts to check /usr/local/lib.  I can't find any configuration 
> item that affects that.  How can this be fixed?
> 

What's the value of "ldconfig_paths" in rc.conf(5)?

That includes:
/etc/rc.conf
/etc/rc.conf.local (if it exists)
/etc/defaults/rc.conf

Here on my 9.0-R system it has the following in /etc/defaults/rc.conf:
/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: simple patch for portsnap to use wget

2012-11-29 Thread Devin Teske
What…

env http_proxy=user:pass@server:port fetch ...

doesn't work for you?
-- 
Devin

On Nov 29, 2012, at 5:50 AM, Luca Ferrari wrote:

> On Wed, Nov 28, 2012 at 2:41 PM, Vincent Hoffman  wrote:
>> Have you tried using
>> HTTP_PROXY_AUTH variable as per fetch(3) instead?
>> added in
>> http://svnweb.freebsd.org/base/head/usr.sbin/portsnap/phttpget/phttpget.c?revision=150461&view=markup
> 
> 
> Does not work for me, and looking at the source code it seems that the
> HTTP_PROXY_AUTH is not considering the port part of the variable (that
> is it considers the realm, the username, the password and nothing
> else), but I could be wrong.
> 
> Luca
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Custom Kernel for FreeBSD Installation

2012-12-11 Thread Devin Teske
I built this thing called the "Druid" to handle this (and other) problems.

Here's the idea…

(a) need a custom kernel to install
(b) you need to install said custom kernel to the new distribution else 
first-boot fails

Enter Druid.

Here's how it works:

===

Step 1. Download the source code to the FreeBSD Druid so you can build a custom 
ISO with your custom kernel/kernel-distribution

$ cvs -d:pserver:anonym...@druidbsd.cvs.sourceforge.net:/cvsroot/druidbsd login
# Simply press ENTER at the "CVS password:" prompt

If you want the FreeBSD-9 based sources:

$ cvs -z3 -d:pserver:anonym...@druidbsd.cvs.sourceforge.net:/cvsroot/druidbsd 
co -P druidbsd/druid

or, if you want the FreeBSD-8 based sources:

$ cvs -z3 -d:pserver:anonym...@druidbsd.cvs.sourceforge.net:/cvsroot/druidbsd 
co -P druidbsd/druid83

# Either of these will take approximately 15 minutes to download (so please be 
patient)

# Simply try again if you get the following error:
#   cvs [checkout aborted]: read lock failed - giving up

===

Step 2: Add your custom kernel

$ cd druidbsd/druid/
# or: cd druidbsd/druid83/

$ cp ~/YOURKERNEL mdroot/kernels/YOURKERNEL

$ vi mdroot/boot/menu.rc

# Find the below lines

\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix="kernels/"
set kernel[0]="GENERIC-i386-9.0"
set kernel_suffix=""

# Change to (making YOURKERNEL the first kernel and GENERIC the second)

\ Set kernel paths (see menu_caption[2] below)
set kernel_prefix="kernels/"
set kernel[0]="YOURKERNEL"
set kernel[1]="GENERIC-i386-9.0"
set kernel_suffix=""

# Save the file and exit

# NOTE: At this point, you *could* say "gmake freebsd" and you have FreeBSD-9 
installation media that will use your custom kernel (YOURKERNEL) to boot and 
perform the installation. However, you may have to on to step 3 if that kernel 
is required to boot your newly installed OS

# NOTE: For the 8.x based media, you'll notice that the "kernel_suffix" is 
".kgz" (you will have to kgzip your kernel and make sure it has this suffix 
else you can modify the suffix; all kernels must have the same suffix, whatever 
it is).

===

Step 3: Have the custom kernel installed as part of the OS

$ cd src/freebsd/repos/9.0-RELEASE/kernels/
# rest performed as root
$ mkdir distroot
$ cat generic.?? | tar zxf - -C distroot
$ cd distroot
$ cp YOURKERNEL GENERIC/kernel
# Optional: copy in any "*.symbols" files for debug or extra "*.ko" kernel 
modules into GENERIC/
$ ../../../../tools/distmtree > ../generic.mtree
$ tar czfo ../generic.tgz .
$ cd ..
$ rm -f generic.??
$ split -b 1425408 generic.tgz generic.
$ rm -Rf generic.tgz distroot
# rest performed as you (non-root)
$ ../../../tools/distsum
# This regenerates CHECKSUM.* and *.inf

===

Last, make the custom ISO…

# in the druidbsd/druid or druidbsd/druid83 directory…

./configure && gmake freebsd

# NOTE: GNU make is required. mkisofs is required. And, if you want the ISO to 
work as-intended and support both burning to CD/DVD _and_ writing to USB thumb 
drive, you'll need Perl (which usually comes with the required Bytes.pm module 
-- otherwise, you can do ./configure --disable-isohybrid).

# NOTE: Don't forget that the DRUID installer has both i386 _and_ amd64 
architectures (so if you have a custom kernel for both, you'll need to do both 
repositories in the above-described manner).
-- 
Devin



On Dec 11, 2012, at 6:26 AM, xenophon+freebsd wrote:

> How do I go about replacing the kernel on the FreeBSD installation CDs?
> I assume it's as simple as replacing the relevant files in the ISO
> image, and that if I look at "make release", I can figure out how the CD
> image gets generated. 
> 
> I'm trying to install FreeBSD onto a HP ProLiant DL380 G3 with a Smart
> Array 5i controller, for use as a file server.  Rather than use Smart
> Array's RAID features, I want to use ZFS's RAID-Z1/Z2, so I have
> configured 18 RAID-0 volumes, each consisting of a single drive attached
> to the Smart Array controller.  This totals 18 drives, so at boot time,
> the ciss(4) driver logs the following error:
> 
>   ciss0:  port 0x3000-0x30ff mem
> 0xf05c-0xf05f,0xf04f-0xf04f3fff irq 10 at device 3.0 on pci1
>   ciss0: PERFORMANT Transport
>   ciss0: adapter claims to report absurd number of logical drives
> (18 > 15)
>   device_attach: ciss0 attach returned 6  
> 
> According to Paul Saab
> (http://lserinol.blogspot.com/2012/03/freebsd-ciss-driver-logical-drive-
> limit.html), the constant CISS_MAX_LOGICAL limits the amount of memory
> used by the driver for DMA by default.
> 
> Best wishes,
> Matthew
> 
> -- 
> I FIGHT FOR THE USERS
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i)

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Devin Teske

> On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> 
> On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
>> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
>>> On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
 -BEGIN PGP SIGNED MESSAGE-
>>> 
 o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.
>>> 
>>> Can those options also get added to "bsdconfig"?
>> 
>> You would have to ask the bsdconfig maintainer(s).
>> 
> 
> Cc'ing dteske.
> 

What aspects of bsdconfig need updating?
-- 
Devin
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Devin Teske
Which would you use?

ECDSA?

https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 


"" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
operation", cryptography experts have also expressed concern over the security 
of the NIST recommended elliptic curves,[31] 
 
suggesting a return to encryption based on non-elliptic-curve groups. ""

Or perhaps RSA? (as des@ recommends)

(not necessarily to Glen but anyone that wants to answer)
-- 
Devin


> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> 
> Please see r303716 for details on the relevant commit, but upstream no
> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> keys as soon as possible, otherwise there will be issues when upgrading
> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> 11.0-RELEASE build.
> 
> Glen
> On behalf of: re@ and secteam@
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
> bLbbH2fh5bxDmDXDMdCF
> =LLtP
> -END PGP SIGNATURE-
> ___
> freebsd-annou...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"

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


Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Devin Teske

> On Aug 8, 2016, at 12:39 PM, Bernard Spil  wrote:
> 
> Hi Devin,
> 
> This resource documents the choices pretty well I think
> https://stribika.github.io/2015/01/04/secure-secure-shell.html 
> <https://stribika.github.io/2015/01/04/secure-secure-shell.html>
> Author has made some modifications up to Jan 2016
> https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
>  
> <https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md>
> 
> The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa.
> 
> Even 6.5p1 shipped with 9.3 supports ed25519.
> 
> Cheers,
> 
> Bernard.
> 

Thanks for confirming, Bernard!
-- 
Cheers,
Devin


> On 2016-08-08 19:56, Devin Teske wrote:
>> Which would you use?
>> ECDSA?
>> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>>
>> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover
>> operation", cryptography experts have also expressed concern over the
>> security of the NIST recommended elliptic curves,[31]
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31>>
>> suggesting a return to encryption based on non-elliptic-curve groups.
>> ""
>> Or perhaps RSA? (as des@ recommends)
>> (not necessarily to Glen but anyone that wants to answer)
>> --
>> Devin
>>> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
>>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
>>> Please see r303716 for details on the relevant commit, but upstream no
>>> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
>>> keys as soon as possible, otherwise there will be issues when upgrading
>>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
>>> 11.0-RELEASE build.
>>> Glen
>>> On behalf of:   re@ and secteam@
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
>>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
>>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
>>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
>>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
>>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
>>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
>>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
>>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
>>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
>>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
>>> bLbbH2fh5bxDmDXDMdCF
>>> =LLtP
>>> -END PGP SIGNATURE-
>>> ___
>>> freebsd-annou...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
>>> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"
>> ___
>> freebsd-stable@freebsd.org <mailto:freebsd-stable@freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
>> <mailto:freebsd-stable-unsubscr...@freebsd.org>"

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