dmesg submitting tool

2020-09-04 Thread Nick Holland
A problem I see:  It's often hard to submit a dmesg.
These days, sending e-mail from an arbitrary machine is "difficult",
as it usually requires use of an e-mail relay.  Gathering and sending
a dmesg via many common e-mail clients often ends up mangling the
dmesg in various ways.

Goals for a solution:
* Should not create any additional work for developers.
* Should not require any significant additions to the most basic
OpenBSD install.
* Should be able to hunt for a port with clear, outbound access.
* Should use a sane protocol (not FTP).
* Should ultimately deliver a familiar, useful, plain text e-mail to
OpenBSD developers.
* Should do some basic checking to minimize spam and mangled dmesgs
from ever hitting the OpenBSD Developers.
* Should allow users to review what is about to be sent to OpenBSD.
* Should be stupidly fast and simple for users to use.
* Should be possible to become part of the base OpenBSD install if
decided useful and desirable.

What I came up with:
The script, "senddmesg" and a system to process the submissions,
forwarding on via e-mail to

Protocol: The best option would probably be an HTTP(s) PUT, but the
tools to do that are not part of OpenBSD's base install (well...probably
could be done by perl, but that's above my skill set).  So...looks to me
like sftp is the answer.  Of course, many networks block port 22, so I
set up a redirect on the receiver to allow SFTP over ports 443, 80, and
53 in addition to port 22.

The sending script starts by checking if it is running as root.  If not,
it advises the user that's ok, but less data can be sent, and gives the
user an opportunity to cancel and re-run as root.  It then tries to to do
an SFTP connection to the target system over each of the ports in order
of likelihood for success.  A very short timeout is used (currently one
second) so that if the SFTP client can't get through, it fails and moves
on quickly.

Once a viable port is found, dmesg, usbdevs, pcidump and sysctl hw is
run, collected into a mktemp(1) file, and the user is put into $EDITOR
or vi to look at what is being sent.  When they exit vi, they are
prompted if they wish to send the file or not.

If they wish to proceed, the file is gzip'd, and sftp'd to the dmesg
collection system.  A two second delay takes place, and a another SFTP
connection is made to try to retrieve a status file, which will report
if the file was accepted and forwarded on to or 

On the receiving end, a script looks for new, uploaded files.  If the
file has been received matches the filename format of a likely dmesg
upload, it's unpacked, checked for a few basic things, and if it checks
out, the dmesg file is forwarded to the OpenBSD developers.  Files are
left where they could be accessed by another user less than one second,
files are uploaded with randomized names (from mktemp(1)), and the
directory the chroot user can write to is mode 370, so the uploading
user can't see other uploads that haven't been processed yet.

A Demo system is set up at

You can download the senddmesg script:
 $ sftp

It's a fairly simple ksh script, look it over to make sure I'm not
doing something malicious or stupid, then run it to send a dmesg to *me*.

If you use it to send a dmesg, IT IS NOT GOING TO THE OPENBSD DEVELOPERS
AT THIS TIME.  I'm not auto-forwarding e-mail until a developer says
"do it".  

The dmesg user has a 30kB filesize ulimit and no password, and a few
tricks to make it difficult to use it to pass messages from user to
user via this system.

This is a proof of concept only.  I really don't like the current
senddmesg script, there are quite a few things I want it to do better,
including having options for non-interactive ("just send the dang 
thing!") and command line driven.  However, before I spend a lot
of time making it suck less, I would like some indication that
developers think this is worth going further with.

IF developers wish me to go forward with this, we can talk about
hosting options (or keep using this system, a VPS hosted by Vultr).
I am willing to keep running it for the project.


Maintenance: (man|cvsweb), (openbsd|obsdacvs)

2020-04-13 Thread Nick Holland

The following servers will likely be inaccessible at times or
completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4)
(yes -- 13 hour window) for site network maintenance.



/etc/daily : flexible df output

2019-10-27 Thread Nick Holland
In version 1.78 of /etc/daily, the -i flag was added to the df output.
Apparently, some people run out of inodes.

I only seem to run out of disk space, and too often, my eye skims
the daily report from a machine, looks at the last column,sees a
small percentage, and I decide, "all is good", even if I were
look a couple columns in, the actual disk space is low.

To try to avoid bikeshedding and flopping this back and forth,
I offer this diff.  With no change, daily df output is unchanged.
Those of us that don't worry about running out of inodes, we can
set DF_FLAGS in /etc/daily.local to be whatever we want, in my
case, I like "-hl" (currently, it's "-ikl")

(inline and attached)

Index: daily
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.93
diff -u -r1.93 daily
--- daily   9 Sep 2019 20:02:26 -   1.93
+++ daily   27 Oct 2019 18:03:18 -
@@ -44,6 +44,10 @@
 start_part "Running daily.local:"
 run_script "daily.local"
+if [ -z "$DF_FLAGS" ]; then
+   DF_FLAGS="-ikl"
 next_part "Removing scratch and junk files:"
 if [ -d /tmp -a ! -L /tmp ]; then
cd /tmp && {
@@ -140,7 +144,7 @@
 if [ "X$VERBOSESTATUS" != X0 ]; then
echo ""
echo "disks:"
-   df -ikl
+   df "$DF_FLAGS"
echo ""
dump W
Index: daily
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.93
diff -u -r1.93 daily
--- daily   9 Sep 2019 20:02:26 -   1.93
+++ daily   27 Oct 2019 18:24:16 -
@@ -44,6 +44,10 @@
 start_part "Running daily.local:"
 run_script "daily.local"
+if [ -z "$DF_FLAGS" ]; then
+   DF_FLAGS="-ikl"
 next_part "Removing scratch and junk files:"
 if [ -d /tmp -a ! -L /tmp ]; then
cd /tmp && {
@@ -140,7 +144,7 @@
 if [ "X$VERBOSESTATUS" != X0 ]; then
echo ""
echo "disks:"
-   df -ikl
+   df "$DF_FLAGS"
echo ""
dump W

Re: right/ tzdata files (was ports@ Re: (Mozilla) Thunderbird time zone issue)

2019-10-26 Thread Nick Holland
On 2019-10-26 09:32, Mark Kettenis wrote:
>> From: "Todd C. Miller" 
>> Date: Sat, 26 Oct 2019 06:55:02 -0600
>> On Sat, 26 Oct 2019 12:15:33 +0100, Stuart Henderson wrote:
>> > The way these files are supposed to work is that you set the system
>> > clock to the time with leap-seconds included (UTC+leap, or TAI-10) and
>> > copy the entire "right" set of files to the main zoneinfo directory
>> > (upstream provides them as parallel directories to encourage this).
>> >
>> > And everyone else sets the system clock to UTC and uses the "posix" files.
>> >
>> >
>> >
>> > We don't have much support for a non-UTC system clock (e.g. openntpd only
>> > seems to copy the flag from the server and doesn't use it to adjust the
>> > clock), and the files definitely cause some confusion. Should we follow
>> > FreeBSD and Solaris and not install the leap-second files at all?
> NTP leapsecond support isn't really related to the use of these files
> though.  In fact, it mostly exists to support the POSIX interpretation
> of time_t.
> The fundamental problem with the "right" files is that the time_t
> values end up being different from their POSIX values for the same UTC
> time.  So whenever these are stored and compared between systems (or
> environments that set the TZ environment variable) things get weird.
>> I think so.  Unless there are programs that use these files directly
>> I don't see a real use for them.
> Agreed.  Software that really cares probably has its own leap-second
> table and will actually rely on the POSIX definition of time_t to
> convert times into human readable form.  That's at least what the
> software I've seen and written does ;).

well...using the "normal" set seems to have done wonderful things
for my computer's problem.  So, yeah, I guess they probably fall under
the "more trouble than they are worth" category.


Re: small detail on faq current upgrade guide.

2019-03-13 Thread Nick Holland
On 3/13/19 7:03 AM, Janne Johansson wrote:
> Since some confusion was noticed about this sentence, this might make
> it clearer:
> -Upgrading to -current by compiling your own source code is not supported.
> +Upgrading to -current from a release by compiling your own source
> code is not supported.

Last I heard, upgrading from /anything/ to current by source code is not
supported.  If you want current, install a snapshot.  Compiling is for
making or testing code AFTER you have upgraded to the most recent snapshot.

So, I think this is going the wrong direction.


Re: request for testing: patch for boot loader out of mem

2018-12-13 Thread Nick Holland
On 12/11/18 08:09, Otto Moerbeek wrote:
> On Mon, Dec 10, 2018 at 11:44:47AM +0100, Otto Moerbeek wrote:
>> On Mon, Dec 10, 2018 at 08:30:10AM +0100, Otto Moerbeek wrote:
>> > Hi,
>> > 
>> > the bootloader uses a very simple allocator for dynamic memory. It
>> > maintains a list of free allocations. If it needs a block, it searches
>> > the freelist and returns the smallest allocation that fits.
>> > 
>> > Allocation patterns like this (starting with an empty freelist)
>> > 
>> > alloc(big)
>> > free(big)
>> > alloc(small)
>> > 
>> > will assigned a big block for the small allocation, wasting most
>> > memory. The allocator does not split up this block. After this, a new
>> > big allocation will grow the heap with the big amount. This diff
>> > changes the strategy by not re-using a block from the free list if
>> > half the space or more would be wasted. Instead, it grows the heap by
>> > the requested amount.
>> > 
>> > This make it possible for me to boot using a root fs with a large
>> > blocksize. There have been several reports of large roots not working
>> > (the bootloader allocates memory based om the blocksize of the file
>> > system, and by default larger filesystems use larger blocks).
>> > 
>> > How to test
>> > ===
>> > 
>> > Apply diff and do a full build including building release. After that,
>> > either upgrade using your newly built cd64.iso, bsd.rd or other
>> > mechanism or do a full install. Test that you can boot afterwards.
>> > 
>> > This needs to be tested on various platforms, both will small and big
>> > (> 600G) root filesystems.  Yes, this is tedious, but we want large
>> > coverage of different cases.
>> > 
>> >-Otto
>> As it turns out by my own testing, on amd64 root filssytems using 32k
>> blocks now work fine, but 64k fs blocks still hit a ceiling. This
>> corresponds to > 512G disks if you use the defaults.
>>  -Otto
> New diff that also works on root filesystems > 500G. It avoid using a
> large bouncebuffer by reding large buffers in a loop instead of one go.
>   -Otto

You are my hero.
Seems it is possible to hose a system by making a 32k block size on a
system with a root file system of only 500MB.  I really don't know how I
did this, much less why, but it's been causing me reboot problems for
over a year now.

Upgraded to today's snap, problem solved.


/home/nick $ dmesg|head  
OpenBSD 6.4-current (GENERIC.MP) #510: Thu Dec 13 06:20:42 MST 2018

> p m
OpenBSD area: 64-2000397735; size: 976756.7M; free: 859532.4M
#size   offset  fstype [fsize bsize   cpg]
  a:   502.0M   64  4.2BSD   4096 32768 1 # / # wtf?
  b: 20473.5M   1048578560swap# 
  c:976762.3M0  unused
  d: 10244.6M   1090508288  4.2BSD   2048 16384 1 # /usr
  e:  4094.7M   489152  4.2BSD   2048 16384 1 # /tmp
  f: 10236.7M   1119875072  4.2BSD   2048 16384 1 # /var
  g: 20473.5M   1161804704  4.2BSD   2048 16384 1 # /repo
  h: 10236.7M   1140839904  4.2BSD   2048 16384 1 # /home
  i: 7.8M   1203734368  4.2BSD   2048 16384 1 # 
  j: 40954.8M   1203750432  4.2BSD   2048 16384 1 

> Index: arch/amd64/stand/libsa/biosdev.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/libsa/biosdev.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 biosdev.c
> --- arch/amd64/stand/libsa/biosdev.c  10 Aug 2018 16:41:35 -  1.32
> +++ arch/amd64/stand/libsa/biosdev.c  11 Dec 2018 13:00:02 -
> @@ -340,11 +340,26 @@ biosd_io(int rw, bios_diskinfo_t *bd, u_
>   return error;
>  }
> +#define MAXSECTS 32
> +
>  int
>  biosd_diskio(int rw, struct diskinfo *dip, u_int off, int nsect, void *buf)
>  {
> - return biosd_io(rw, >bios_info, off, nsect, buf);
> + int i, n, ret;
> +
> + /*
> +  * Avoid doing too large reads, the bounce buffer used by biosd_io()
> +  * might run us out-of-mem.
> +  */
> + for (i = 0, ret = 0; ret == 0 && nsect > 0;
> + i += MAXSECTS, nsect -= MAXSECTS) {
> + n = nsect >= MAXSECTS ? MAXSECTS : nsect;
> + ret = biosd_io(rw, >bios_info, off + i, n,
> + buf + i * DEV_BSIZE);
> + }
> + return ret;
>  }
> +
>  /*
>   * Try to read the bsd label on the given BIOS device.
>   */
> @@ -715,7 +730,6 @@ biosstrategy(void *devdata, int rw, dadd
>  size_t *rsize)
>  {
>   struct diskinfo *dip = (struct diskinfo *)devdata;
> - bios_diskinfo_t *bd = >bios_info;
>   u_int8_t error = 0;
>   size_t nsect;
> @@ -732,7 +746,7 @@ biosstrategy(void *devdata, int rw, dadd
>   if (blk < 0)
>   error = EINVAL;
>   else
> - error = biosd_io(rw, bd, 

planned outage: openbsd.cs.toronto,edu,,

2018-01-03 Thread Nick Holland

Due to facilities maintenance, the following resources will be
unavailable from somewhere around Jan 3 8:30pm EST until Jan 7 8:30am EST:
  * openbsd.cs.toronto,edu

Thanks for your patience!


acme-client doc diff

2017-03-18 Thread Nick Holland
I found that the current man pages and example file for acme-client
are confusing and leave one with an imperfect certificate setup, with
the intermediate certs missing.  Doesn't generate an error on
OpenBSD, but does on some other OSs.  So I propose these changes to
the example file and man pages:

/etc/acme-client.conf: fetch a "domain full chain certificate" rather
than the "domain chain certificate" (I'd be happy with fetching both,
one extra tiny file won't hurt anything)

acme-client(1) : I know what a "host" key is, didn't recognize it in
this man page.  Also couldn't figure out how to generate the initial
host key without the help of the commit message. 

The example in /etc/acme-client.conf shows "", but in 
acme-client(1), it's "".  Not interchangeable, so
standardize on "".

acme-client.conf(5) : Point out "full chain" is needed for
httpd(8) (and others, I'm sure).  Show a httpd.conf(5) server block.

Diff below is certainly tab mangled; raw diff can be pulled from:


Index: etc/acme-client.conf
RCS file: /cvs/src/etc/acme-client.conf,v
retrieving revision 1.3
diff -u -u -r1.3 acme-client.conf
--- etc/acme-client.conf21 Jan 2017 09:06:57 -  1.3
+++ etc/acme-client.conf18 Mar 2017 02:44:58 -
@@ -17,6 +17,6 @@
 #  alternative names { }
 #  domain key "/etc/ssl/private/"
 #  domain certificate "/etc/ssl/"
-#  domain chain certificate "/etc/ssl/"
+#  domain full chain certificate "/etc/ssl/"
 #  sign with letsencrypt
Index: usr.sbin/acme-client/acme-client.1
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.1,v
retrieving revision 1.20
diff -u -u -r1.20 acme-client.1
--- usr.sbin/acme-client/acme-client.1  28 Jan 2017 17:53:17 -  1.20
+++ usr.sbin/acme-client/acme-client.1  18 Mar 2017 02:44:58 -
@@ -34,7 +34,7 @@
 The options are as follows:
 .Bl -tag -width Ds
 .It Fl A
-Create a new RSA account key if one does not already exist.
+Create a new RSA account (host) key if one does not already exist.
 .It Fl D
 Create a new RSA domain key if one does not already exist.
 .It Fl F
@@ -98,11 +98,16 @@
 returns 1 on failure, 2 if the certificates didn't change (up to date),
 or 0 if certificates were changed (revoked or updated).
+To initialize a new account (host) key:
+.Dl # acme-client -vAD
 To create and submit a new key for a single domain, assuming that the
 web server has already been configured to map the challenge directory
 as above:
-.Dl # acme-client -vD
+.Dl # acme-client -vD
 A daily
 .Xr cron 8
@@ -110,7 +115,7 @@
 .Bd -literal -offset indent
 #! /bin/sh
 if [ $? -eq 0 ]
Index: usr.sbin/acme-client/acme-client.conf.5
RCS file: /cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.8
diff -u -u -r1.8 acme-client.conf.5
--- usr.sbin/acme-client/acme-client.conf.5 21 Jan 2017 15:53:15 -  
+++ usr.sbin/acme-client/acme-client.conf.5 18 Mar 2017 02:44:58 -
@@ -134,6 +134,12 @@
 It needs to be in the same directory as the
 .Ar domain certificate
 (or in a subdirectory) and can be specified as a relative or absolute path.
+This is a combination of the
+.Ar domain certificate
+and the
+.Ar domain chain certificate
+in one file, and is required for many web servers, including
+.Xr httpd 8 .
 .It Ic sign with Ar authority
 The certificate authority (as declared above in the
@@ -151,8 +157,28 @@
alternative names { }
domain key "/etc/ssl/private/"
domain certificate "/etc/ssl/"
+   domain full chain certificate "/etc/ssl/"
sign with letsencrypt
challengedir "/var/www/acme"
+.Xr httpd.conf 5
+server declaration to use that certificate looks like this:
+.Bd -literal -offset indent
+server "" {
+alias ""
+alias ""
+listen on $ext_addr port 80
+listen on $ext_addr tls port 443
+tls certificate "/etc/ssl/"
+tls key "/etc/ssl/private/"
+location "/.well-known/acme-challenge/*" { 
+root "/acme" 
+root strip 2 
+root "/htdocs"

Re: [WWW] Reverse chronological order for faq/current.html

2017-01-24 Thread Nick Holland
On 01/24/17 04:06, Raf Czlonka wrote:
> Another way to look at it is, "Let me have a look if there's anything
> new on faq/current.html - I open the page and, *without* moving
> forward, can see straight away if something new has been added. No?
> Then I move on with my life without scrolling down or doing anything
> else apart from opening the page". Given OpenBSD's rapid development,
> new entries on faq/current.html appear quite frequently - I'm only
> thinking of the tiny amount of time saved each time.

What I think you are not thinking of is that in addition to being a list
of things that have changed, it is also a list of changes that have to
be done ... often IN PARTICULAR ORDER.

As it is, you read down until you hit where you are, then follow the
instructions in order.  "more difficult" in your argument, but logical.

As you propose, you read down until you find where you are not, then
change directions and read backwards.  That's not intuitive, normal, or
reasonable to expect.  Most likely, your plan will have people making
changes in reverse order...which may often work, but sometimes
won't...and won't be the order the developers will be testing.


Mirror downage:,,,

2016-05-25 Thread Nick Holland

Due to a infrastructure upgrade, power to the mirror and other systems
at University of Toronto, will be interrupted sometime Thursday, after
9:30pm Toronto time (EDT -- UTC-4), and should be restored Friday by
7:30am EDT.

This will impact:

Sorry for any inconvenience this might cause.


University of Toronto Mirror upcoming outages

2015-12-08 Thread Nick Holland

A heads-up for users of the University of Toronto mirror

The University will be doing some power systems maintenance this week
and next, and anticipate two planned outages:

* Thursday,  December 10 11:00p EST to Friday December 11, 7:00am EST
* Wednesday, December 16 11:00p EST to Thursday December 17, 7:00am EST

The mirror will be unavailable during these periods.



Re: Invalid HTML entities in upgrade57.html

2015-09-26 Thread Nick Holland
On 09/25/15 12:57, Kevin Zhang wrote:
> Using >, & in raw text is invalid HTML.

Not according to
And unless you can point to an actual PROBLEM...this makes the page a
lot more of a pain to maintain.

There was an actual validation problem, which you prompted me to test
for and, so thanks, but these were not them.

(who would love to get his hands around the neck of the people that
decided that the most common Unix special characters would be special
characters in HTML, where much Unix is documented...)

> Index: faq/upgrade57.html
> ===
> RCS file: /cvs/www/faq/upgrade57.html,v
> retrieving revision 1.8
> diff -u -p -r1.8 upgrade57.html
> --- faq/upgrade57.html  8 Jul 2015 01:11:32 -   1.8
> +++ faq/upgrade57.html  25 Sep 2015 16:55:53 -
> @@ -40,24 +40,24 @@ function flip_visibility(id) {
> -[4.0 -> 4.1] |
> -[4.1 -> 4.2] |
> -[4.2 -> 4.3] |
> -[4.3 -> 4.4] |
> -[4.4 -> 4.5] |
> -[4.5 -> 4.6]
> +[4.0 - 4.1] |
> +[4.1 - 4.2] |
> +[4.2 - 4.3] |
> +[4.3 - 4.4] |
> +[4.4 - 4.5] |
> +[4.5 - 4.6]
> -[4.6 -> 4.7] |
> -[4.7 -> 4.8] |
> -[4.8 -> 4.9] |
> -[4.9 -> 5.0] |
> -[5.0 -> 5.1] |
> -[5.1 -> 5.2]
> +[4.6 - 4.7] |
> +[4.7 - 4.8] |
> +[4.8 - 4.9] |
> +[4.9 - 5.0] |
> +[5.0 - 5.1] |
> +[5.1 - 5.2]
> -[5.2 -> 5.3] |
> -[5.3 -> 5.4] |
> -[5.4 -> 5.5] |
> -[5.5 -> 5.6] |
> +[5.2 - 5.3] |
> +[5.3 - 5.4] |
> +[5.4 - 5.5] |
> +[5.5 - 5.6] |
>  [FAQ Index]
> @@ -251,7 +251,7 @@ on platform.
>  export RELEASEPATH=/usr/rel   # where you put the
> files
> -rm /obsd ; ln /bsd /obsd && cp /nbsd && mv /nbsd /bsd
> +rm /obsd ; ln /bsd /obsd  cp /nbsd  mv /nbsd
> /bsd
>  cp bsd.rd /
>  cp bsd /bsd.sp
> @@ -260,7 +260,7 @@ on platform.
>  export RELEASEPATH=/usr/rel   # where you put the
> files
> -rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
> +rm /obsd ; ln /bsd /obsd  cp bsd /nbsd  mv /nbsd
> /bsd
>  cp bsd.rd /
>  (note: you will get a harmless error message if your platform doesn't
> @@ -628,12 +628,12 @@ Major update to 9.4.0. A dump/restore is
>  The twentytwelve theme from wordpress 4.0.x is no longer included with
>  wordpress 4.1.x. If you are using this theme, back it up before updating:
> -   cd /var/www/wordpress/wp-content/themes &&
> +   cd /var/www/wordpress/wp-content/themes 
> cp -Rp twentytwelve twentytwelve.bak
>  and restore it after wordpress update:
> -   cd /var/www/wordpress/wp-content/themes &&
> +   cd /var/www/wordpress/wp-content/themes 
> mv twentytwelve.bak twentytwelve
> @@ -674,24 +674,24 @@ chapter of the FAQ for more information.
> -[4.0 -> 4.1] |
> -[4.1 -> 4.2] |
> -[4.2 -> 4.3] |
> -[4.3 -> 4.4] |
> -[4.4 -> 4.5] |
> -[4.5 -> 4.6]
> +[4.0 - 4.1] |
> +[4.1 - 4.2] |
> +[4.2 - 4.3] |
> +[4.3 - 4.4] |
> +[4.4 - 4.5] |
> +[4.5 - 4.6]
> -[4.6 -> 4.7] |
> -[4.7 -> 4.8] |
> -[4.8 -> 4.9] |
> -[4.9 -> 5.0] |
> -[5.0 -> 5.1] |
> -[5.1 -> 5.2]
> +[4.6 - 4.7] |
> +[4.7 - 4.8] |
> +[4.8 - 4.9] |
> +[4.9 - 5.0] |
> +[5.0 - 5.1] |
> +[5.1 - 5.2]
> -[5.2 -> 5.3] |
> -[5.3 -> 5.4] |
> -[5.4 -> 5.5] |
> -[5.5 -> 5.6] |
> +[5.2 - 5.3] |
> +[5.3 - 5.4] |
> +[5.4 - 5.5] |
> +[5.5 - 5.6] |
>  [FAQ Index]

Re: Fix some titles

2015-07-07 Thread Nick Holland
On 07/07/15 06:34, Pavel Plamenov wrote:
 Updated patch, paying more attention to style.
 Index: plus52.html
yep, I like those.  Thanks!


 RCS file: /cvs/www/plus52.html,v
 retrieving revision 1.11
 diff -u -p -r1.11 plus52.html
 --- plus52.html   2 Jul 2015 05:49:04 -   1.11
 +++ plus52.html   7 Jul 2015 10:31:28 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.2 changes/title
  meta name=description content=OpenBSD 5.2 changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: plus53.html
 RCS file: /cvs/www/plus53.html,v
 retrieving revision 1.10
 diff -u -p -r1.10 plus53.html
 --- plus53.html   2 Jul 2015 05:49:04 -   1.10
 +++ plus53.html   7 Jul 2015 10:31:28 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.3 changes/title
  meta name=description content=OpenBSD 5.3 changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: plus54.html
 RCS file: /cvs/www/plus54.html,v
 retrieving revision 1.12
 diff -u -p -r1.12 plus54.html
 --- plus54.html   2 Jul 2015 05:49:04 -   1.12
 +++ plus54.html   7 Jul 2015 10:31:28 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.4 changes/title
  meta name=description content=OpenBSD -current changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: plus55.html
 RCS file: /cvs/www/plus55.html,v
 retrieving revision 1.8
 diff -u -p -r1.8 plus55.html
 --- plus55.html   2 Jul 2015 05:49:04 -   1.8
 +++ plus55.html   7 Jul 2015 10:31:28 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.5 changes/title
  meta name=description content=OpenBSD -current changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: plus56.html
 RCS file: /cvs/www/plus56.html,v
 retrieving revision 1.9
 diff -u -p -r1.9 plus56.html
 --- plus56.html   2 Jul 2015 05:49:04 -   1.9
 +++ plus56.html   7 Jul 2015 10:31:28 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.6 changes/title
  meta name=description content=OpenBSD 5.6 changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: plus57.html
 RCS file: /cvs/www/plus57.html,v
 retrieving revision 1.4
 diff -u -p -r1.4 plus57.html
 --- plus57.html   2 Jul 2015 05:49:04 -   1.4
 +++ plus57.html   7 Jul 2015 10:31:29 -
 @@ -2,7 +2,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD -current changes/title
 +titleOpenBSD 5.7 changes/title
  meta name=description content=OpenBSD 5.7 changes
  meta name=copyright content=This document copyright 1996-2012 by 
  link rel=canonical href=;
 Index: faq/upgrade35.html
 RCS file: /cvs/www/faq/upgrade35.html,v
 retrieving revision 1.4
 diff -u -p -r1.4 upgrade35.html
 --- faq/upgrade35.html2 Jul 2015 05:49:04 -   1.4
 +++ faq/upgrade35.html7 Jul 2015 10:31:29 -
 @@ -1,7 +1,7 @@
  !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
 -titleOpenBSD Upgrade Guide/title
 +titleOpenBSD Upgrade Guide: 3.5 to 3.6/title
  meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1
  meta name=description   content=the OpenBSD FAQ page
  meta name=copyright content=This document copyright 2004 by OpenBSD
 Index: faq/upgrade36.html
 RCS file: /cvs/www/faq/upgrade36.html,v
 retrieving revision 1.16
 diff -u -p -r1.16 upgrade36.html
 --- faq/upgrade36.html2 Jul 2015 05:49:04 -   1.16
 +++ faq/upgrade36.html7 Jul 

Re: RAM encryption and key storing in CPU

2015-06-13 Thread Nick Holland
On 06/12/15 01:09, ertetlen barmok wrote:
 Any luck with this? 

no luck at all, since your patch to make it happen wasn't attached to
the email, and thus, never should have been sent to tech@.

Personally, it looks like a highly invasive change (which also means
almost certain to introduce OTHER security bugs!) for reducing ONE
physical security risk.  And, I'd hardly call it the major physical
security risk.

For the OP:
Most of you probably know exactly what that is, no reason to click on it. :)

If your data is important, physical security is important.  Your
proposed task-for-others doesn't change this.  Doesn't solve key
loggers, doesn't solve smart hw monitoring the server, doesn't prevent
rubber hose decryption, etc.


  Original Message 
 From: ertetlen barmok
 Apparently from:
 Subject: RAM encryption and key storing in CPU
 Date: Sat, 23 May 2015 05:15:47 -0400
 Everything is stored in plaintext in the Memory.
 So if although full disc encryption is used on an OpenBSD machine, it is 
 possible to copy the content of the memory, while the notebook was on 
 suspend or it was running:
 Can we (optionally*) encrypt the content of the memory and store the key for 
 decryption in the CPU to avoid in general these kind of attacks?
 There are solutions for this on Linux already, but only on patch level:
 *if someone would want to harden it's OpenBSD (since notebooks could be 
 stolen..) it could turn on this feature to avoid a policy to always turn off 
 the notebook while not using it.
 Thank you for your comments.

Re: [patch] faq12 - blobs

2015-06-07 Thread Nick Holland
On 06/06/15 11:35, Todd Mortimer wrote:
 Hi tech@
 It seems that this question comes up frequently enough that people might be 
 of answering it. 
 Not sure if this is the right spot in the FAQ to put this, or even if this is 
 that people want included in there at all. Rejections, corrections and 
 bikeshedding welcome. 

I'm not against this, but lemme see what I can come up with, got a few
additional points I'd like made.


 Index: faq12.html
 RCS file: /cvs/www/faq/faq12.html,v
 retrieving revision 1.117
 diff -u -p -u -p -r1.117 faq12.html
 --- faq12.html25 May 2015 03:48:24 -  1.117
 +++ faq12.html6 Jun 2015 15:17:36 -
 @@ -41,6 +41,7 @@ Questions/font/h1
lia href=#ami12.1.7 - My ami(4) card will only support one
 logical disk!/a
lia href=#cryptohw12.1.8 - How do I activate my crypto accelerator 
 +  lia href=#blobs12.1.9 - Does OpenBSD include any binary-only device 
 drivers (blobs)?/a
  lia href=#alpha12.2 - DEC Alpha /a
  lia href=#amd6412.3 - AMD 64/a
 @@ -280,6 +281,41 @@ much or all of the benefit of offloading
  Your results may vary widely depending on the task you have to
 +h3 id=blobs12.1.9 - Does OpenBSD include any binary-only device drivers 
 +No. The source code for all of the device drivers in the OpenBSD kernel is
 +available in a href=;CVS/a. OpenBSD 
 +rejected binary device drivers (a.k.a. blobs) for many years, and this was 
 +the subject of the a href=;3.9 
 release song/a, 
 +which was released in 2006. 
 +Some people are confused about the distinction between device drivers,
 +which run in the kernel, and firmware, which runs on the many hardware
 +parts that collectively make up your computer. Devices such as hard
 +disks, network cards, and even CPUs generally contain firmware that runs on 
 the device
 +itself and transforms the physical collection of transistors and
 +wires into something that acts like a hard disk, network card or CPU.
 +This firmware is usually included with the device itself on a ROM chip.
 +In some cases the vendor does not include the firmware with the device, 
 +and expects the firmware to be loaded onto the device at run time by the
 +operating system. For these cases, OpenBSD can load the firmware onto the 
 +and includes the 
 +utility, which can fetch non-free firmware from the Internet if the vendor 
 +made it available. 
 +Before posting to the mailing lists and objecting to binary firmware,
 +please remember that firmware does not run in the kernel (and is therefore 
 not a
 +part of the operating system), and if it is not loaded onto the device at run
 +time, then that usually means that it was loaded from ROM when the device was
 +powered on. Users who wish to use only hardware which has freely available
 +firmware source code are encouraged to seek out and buy only that hardware. 
 +OpenBSD does not yet support that hardware, then users can submit new device 
 +or patches to the a 
 +mailing list.
  h2 id=alpha12.2 - DEC Alpha/h2
  [nothing yet]

Re: [PATCH] FTP as an install method is no more

2015-06-05 Thread Nick Holland
On 06/05/15 01:15, Raf Czlonka wrote:
 Hi all,
 I think I got the most obvious ones but there might still be other ones
 scattered among the web pages.
 I'm not entirely sure how does that leave the exact wording of
 'ftp.html' in terms of Download via HTTP/FTP, etc. vs. Install via
 ... so I left it unchanged for now.

yeah, there are a few other things to look at on that one, AND ftp.html
is a generated file, so I haven't committed this yet (a little more than
I can do before running off to work in the morning!).  faq1.html and
faq4.html, though, I've committed.

 There's also the text version of the FAQ ('faq/obsd-faq.txt') which I
 haven't updated as it seems to be generated from the HTML version so
 that needs to be done separately - it doesn't seem like this has been
 done for 5.7 release at all as there's an answer to What's new in
 OpenBSD 5.6? section with 5.6 changes (not just the actual question
 like below in the faq1.html).

regenerated and committed, thanks!


 Index: ftp.html
 RCS file: /cvs/www/ftp.html,v
 retrieving revision 1.669
 diff -u -p -r1.669 ftp.html
 --- ftp.html  11 May 2015 11:19:50 -  1.669
 +++ ftp.html  5 Jun 2015 05:04:11 -
 @@ -64,7 +64,7 @@ upgrade your system very quickly.
  h3font color=#e0a name=mirrorsDownload via
 -OpenBSD can be also easily installed via HTTP or FTP.
 +OpenBSD can also be easily installed via HTTP.
  Typically you need a single small piece of boot media (e.g., a boot floppy)
  and then the rest of the files can be installed from a number of locations,
  including directly off the Internet.
 Index: faq/faq1.html
 RCS file: /cvs/www/faq/faq1.html,v
 retrieving revision 1.147
 diff -u -p -r1.147 faq1.html
 --- faq/faq1.html 25 May 2015 15:32:00 -  1.147
 +++ faq/faq1.html 5 Jun 2015 05:04:11 -
 @@ -36,7 +36,7 @@ please, use a max of 72 chars per line -
  lia href=#WhoMaintains1.6 - Who maintains OpenBSD?/a
  lia href=#Next1.7 - When is the next release of OpenBSD?/a
  lia href=#Included1.8 - What is included with OpenBSD?/a
 -lia href=#WhatsNew1.9 - What is new in OpenBSD 5.6?/a
 +lia href=#WhatsNew1.9 - What is new in OpenBSD 5.7?/a
  lia href=#Desktop1.10 - Can I use OpenBSD as a desktop system?/a
  lia href=#HowAbout1.11 - Why is/isn't iProductX/i included?/a
 Index: faq/faq4.html
 RCS file: /cvs/www/faq/faq4.html,v
 retrieving revision 1.355
 diff -u -p -r1.355 faq4.html
 --- faq/faq4.html 25 May 2015 15:32:00 -  1.355
 +++ faq/faq4.html 5 Jun 2015 05:04:11 -
 @@ -235,7 +235,7 @@ You will want to know the following item
liIf ISA, you also need to know hardware settings, and confirm
they are as OpenBSD requires.
 -liInstall method to be used (CD-ROM, FTP, etc.).
 +liInstall method to be used (CD-ROM, HTTP, etc.).
  liShould an important bug be found, how will the system be patched?
liIf done locally, you will need to have
 @@ -1079,7 +1079,7 @@ Note that on slow hardware, the Get/Ver
Installing xshare57.tgz 100% |**|  4413 KB00:05
Installing xfont57.tgz  100% |**| 38994 KB00:10
Installing xserv57.tgz  100% |**| 18469 KB00:06
 -  Location of sets? (cd disk ftp http or 'done') [done] biEnter/i/b
 +  Location of sets? (cd disk http or 'done') [done] biEnter/i/b
 @@ -3005,7 +3005,7 @@ Note: if you will be doing your install 
  need to add your ttsite*.tgz/tt file(s) to the file
  ttindex.txt/tt in the source directory in order for them to be
  listed as an option at install time.
 -This is not needed for FTP or other installs.
 +This is not needed for other install methods.
  a name=Multiple/a

Re: [EXTERNAL] Re: Mention pkg-readmes in FAQ

2015-04-26 Thread Nick Holland
On 04/26/15 10:14, Eichert, Diana wrote:
 Point taken, but what about a readme associated with a dependency
 install?  I've seen them buried, even scroll off screen, in pkg
 install with a lot of dependencies.

that's why I added it.

 Then again, most people don't RTFM.

that's why I don't expect to change the world. :)


 -Original Message- From:
 [] On Behalf Of Stuart Henderson Sent:
 Saturday, April 25, 2015 10:07 AM To: trondd Cc: 
 Subject: [EXTERNAL] Re: Mention pkg-readmes in FAQ
 On 2015/04/25 11:21, trondd wrote:
 Seems like I see a lot of people who don't know about pkg-readmes
 and it was a long time before I knew about them, too. Note their
 existence in the package/ports FAQ.
 I don't object to it, but when you install a package with such
 information, it says:
 # pkg_add xl2tpd quirks-2.66 signed on 2015-04-23T10:51:49Z 
 xl2tpd-1.3.1p5: ok The following new rcscripts were installed:
 /etc/rc.d/xl2tpd See rcctl(8) for details. Look in
 /usr/local/share/doc/pkg-readmes for extra documentation.
 If people don't manage to find it when it's right in front of them,
 what hope is there of them noticing it in the FAQ?
 --- faq15.html  27 Feb 2015 09:16:26 -  1.105 +++
 faq15.html  25 Apr 2015 15:18:01 - @@ -370,6 +370,9 @@ scaled.
 Below is the relevant section fr /pre/blockquote
 p +Additionally, some packages provide configuration and other 
 +information in a file located in
 i/usr/local/share/docs/pkg-readmes/i. +p Let us now continue
 with an example of a package which has dependencies:

Re: Do you need/prefer the non-DUID option in the installer?

2015-03-15 Thread Nick Holland
On 03/15/15 14:59, Jiri B wrote:
 On Sun, Mar 15, 2015 at 11:24:32AM -0400, Kenneth Westerback wrote:
 Using DUIDs in the installed /etc/fstab has been the default for some time 
 We'd like to eliminate the question in the installer and just use
 DUIDs unconditionally.
 But first we need to know you are aware of any circumstances where
 people need or prefer to use the non-DUID option when installing?
 iirc nick@ once said he uses /altroot and thus doesn't
 use duids. but event it is still the truth it is unusual

thanks, I can get myself in trouble without your help. ;)
(tl;dr version: I'm fine with the installer becoming DUID-only)

There are some cases where I like to use non-DUID labels.  However,
these are all non-standard cases where one has to do manual editing
ANYWAY, and thus, switching over to non-DUIDs is a non-issue (and even
there, it's usually just a few lines, the rest stay -- and need to stay
-- DUID!)

Unix-Philosophically speaking, I like non-DUIDs.  They are simple things
in the /dev directory.  One doesn't really have to understand much about
OpenBSD to see /dev/sd0h and have some idea what it means.
e4fc87e6abfa5e45.h is not so obvious, 'specially to those who have seen
Solaris and their c1t2d0s3 style notation which might look superficially
similar.  One really still needs to understand the non-DUID notation,
too, so DUID is One More Thing to learn.  It's a step away from the
simplicity that has been an OpenBSD trait, and I can't type or remember
sixteen characters in a row accurately.

BUT as anyone who fiddled with USB disks or softraid has seen, there are
issues with non-DUIDs.  DUIDs are very important to have, modern systems
without it would be ... difficult. And learning them takes about 60
seconds, no big deal.  You must be this --  --- smart to ride this

Score, at least to me:
 Problems solved by DUIDs: lots
 Problems CREATED by DUIDs: none (that I have found)

Lots to zero.  I'm more than happy to flip the switch to DUID only in
the installer.


Re: FAQ 14.9: installboot example parameters reversed

2015-02-26 Thread Nick Holland
On 02/26/15 05:44, Rolf Sommerhalder wrote:
 While salvaging a CompactFlash with a corrupt partition table, I
 noticed that the example in
 appears to be outdated:
  # cd /usr/mdec; ./installboot /boot biosboot sd0
 According to installboot(8), the syntax is:
  installboot [-nv] [-r root] disk [stage1 [stage2]]
 e.g. the example should read:
  # cd /usr/mdec; ./installboot sd0 biosboot /boot
  installboot -v sd0 /usr/mdec/biosboot /boot
 or finally, if sd0a is mounted on /mnt:
   installboot -v -r /mnt/ sd0 /usr/mdec/biosboot /mnt/boot

yes, that section is wrong, but your correction is wrong and incomplete.
The whole point of the rework of installboot was to de-platform-specific
it, and to have sane defaults, thus the new syntax will be just
installboot sd0, and (current) installboot is not in /usr/mdec anymore.

I got to think about this...I'm not sure there's even any merit to this
section anymore.  Proper answer might be delete it.


Re: faq: remove references to aucat -M option

2015-02-23 Thread Nick Holland
On 02/23/15 04:03, Alexandre Ratchov wrote:
 The -M option of aucat was removed long time ago, and as we're at
 it mention about softsynths.

ok nick@, but as I'd consider you an authority on this area, please skim
through the rest of this section looking for similar out-of-date-ness.


 Index: faq13.html
 RCS file: /cvs/www/faq/faq13.html,v
 retrieving revision 1.152
 diff -u -p -u -p -r1.152 faq13.html
 --- faq13.html1 Dec 2014 09:49:46 -   1.152
 +++ faq13.html23 Feb 2015 08:53:42 -
 @@ -808,23 +808,25 @@ umidi1 at uhub1 port 2 configuration 1 i
  midi1 at umidi1: lt;USB MIDI I/Fgt;
 -It shows three MIDI ports, corresponding to:
 +It shows three MIDI ports, known by
 +a href=;sndio(7)/a
 -li tt/dev/rmidi0/tt - synthesizer connected by USB
 -li tt/dev/rmidi1/tt - a MIDI master keyboard
 +li ttrmidi/0/tt - synthesizer connected by USB
 +li ttrmidi/1/tt - a MIDI master keyboard
 -These devices are known by
 -a href=;sndio(7)/a
 -as ttrmidi/0/tt and ttrmidi/1/tt.
 +They are backed by the tt/dev/rmidi0/tt and tt/dev/rmidi1/tt
 +character devices.
 +The later are handly for testing the hardware, bypassing most software 
  To test your MIDI keyboard, you can use the
  utility to display MIDI data you're playing on it:
 -$ strongaucat -Mq rmidi/1 -o - | hexdump -e '1/1 %02x\n'/strong
 +$ stronghexdump -e '1/1 %02x\n' lt; /dev/rmidi0/strong
 @@ -835,14 +837,11 @@ The output of the keyboard can be connec
  synthesizer, as follows:
 -$ strongaucat -M -q rmidi/0 -q rmidi/1/strong
 +$ strongcat -u lt; /dev/rmidi0 gt; /dev/rmidi1/strong
  Now you can hear on the synthesizer what you're playing on the MIDI
 -Refer to the 
 -manual page for further information.
  !-- h3Playing, recording MIDI sequences/h3 --
 @@ -854,6 +853,19 @@ is as easy as:
  $ strongmidiplay -f rmidi/0 file.mid/strong
 +a href=;sndiod(1)/a
 +server exposes MIDI thru ports, allowing programs to send each other
 +MIDI data.
 +For instance, if you have no hardware synthsizer connected, you could
 +start a software one (like the audio/fluidsynth port), and then use
 +it as MIDI output:
 +$ strongmidiplay -f midithru/0 file.mid/strong

Re: [DIFF] /etc/rc: gracefully shut down base daemons too

2015-02-17 Thread Nick Holland

On 02/17/15 08:52, Ingo Schwarze wrote:

Shutting down stuff like pflogd and syslogd before the system
is actually going down might even be harmful.

you maybe when doing an upgrade where the newly installed 
binaries are not compatible with the running kernel?

Considering the number of times base daemons have been shut down by 
halting the kernel and the lack of problems caused by this?  no...I 
don't think this is a good idea at all.


Re: faq diff: kerberos

2014-11-27 Thread Nick Holland
On 11/25/14 18:45, J Sisson wrote:
 kerberos was moved to ports, but the docs still link to kerberos(8):
 Does the following diff make sense?  (Apologies in advance if gmail
 mangles the diff, or if the diff needs to be generated with different
 --- www/faq/faq10.html.orig 2014-11-25 15:35:13.828391026 -0800
 +++ www/faq/faq10.html  2014-11-25 15:42:42.269591036 -0800
 @@ -1286,8 +1286,7 @@
  segments carrying YP traffic can bind your YP domain and retrieve its data.
  In some cases, passing YP traffic through SSL or IPSec tunnels
  might be an option, or you might consider combining YP with
 -a href=;sektion=8;
 -kerberos(8)/a authentication.
 +kerberos authentication (available from ports).
  a name=YP_server/a

good spotting, but I'd prefer to remove the kerberos reference all
together (and I did).


Re: rwho on OpenBSD 5.6

2014-11-09 Thread Nick Holland
On 11/09/14 16:07, Job Snijders wrote:
 On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote:
 I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh,
 rshd, rwho, rwhod, etc have been removed (at least according to the
 Changelog). However, the upgrade instructions fail to mention that files
 like /etc/rc.d/rwhod or /usr/bin/rwho should be removed.
 How much of a catastrophy is this?
 Question for the community:  Do you want the upgrade instructions to
 be 100% useful, or 100% complete?
 100% complete should be the goal.
 I expect a system that is upgraded from 5.5 to 5.6 (following the
 upgrade documentation) to be in the _exact_ same state as a clean 5.6
 installation, barring changes local to the system.

See the third paragraph of any of the upgrade documents from 3.7 until
5.5.  I removed that paragraph this release because I figured it was
probably self-evident to people who understood which end of their
digestive tract to put the fresh food into.  Perhaps I overestimated.

I would invite you to give it a shot.
Start with current.html, plus56.html, anything else you wish.  Not a lot
of the developers really care a lot about the document, so they won't
have been keeping current.html super accurate, you are basically on your
own.  You will have a lot of testing to do.  You will note that while
deleting rwhod was undoubtedly exciting for developers, actually putting
it on current.html -- so I could put it on upgrade56.html -- was not
nearly as much fun and never happened

When you get it all done...look at your work.  Can you imagine someone
following it for 50 machines they support?  How about 500?  Can they use
it for all of the 17 or so platforms OpenBSD supports?  Can they do it
from a remote site with no console access?  is it the _exact_ same as
a fresh install?

Oh, to add to the realism, do it while holding down a full-time+ job, a
few other volunteer activities, and cool-ass vehicles that beg to be
driven any time the weather doesn't suck and a significant other you
like to spend time with.

BTW: if you fuck it up, you will cause a lot of people all over the
world to have really really bad days.  So don't fuck up.  No pressure or
anything.  And in less than six months, you get to do it again.  The
good news is, if you do a half-way decent job, only two people complain:
you and one other person (the other person does many things to
contribute to the project, however), and you get lots of positive feedback.

Can you make a better one than me?  Give it a shot.  Really.  It's win
all around.  If you succeed, the community wins.  Do a great job, I can
go spend my time on other things.  Win all around. :)

The goal of the upgradeXX.html document -- as *I* see it -- is to
provide enough information for real administrators of real systems to
take their systems from a functional state of the previous release to a
functional state of the current release, and leave them in a good state
for the NEXT release cycle, too (lather, rinse, repeat, indefinitely).
The idea is to be concise enough that the job can be done quickly and
easily, and yet provide enough details so that virtually all users can
figure out if they have edge cases which might cause them problems.

Is the upgraded system identical to a fresh install?  No; not a goal of
mine.  Will there be ashes left over?  Yes.  I think rwho and friends
probably should have been removed as part of that huge list of files to
delete, but the negative consequences of not deleting rwho are basically
zero.  And someone who's infrastructure depends on it might just be
happy to find that it still runs on some platforms and might give them a
little more time to fix their systems.  That's why we aren't obsessive
about deleting old library files, too -- you may well have applications,
either as packages or things you compiled on your own -- which will
still work on the upgraded system and may actually be really important
for that system to continue to work (or even boot!) until the updated
applications are installed.  Does it work always?  No, but if it saves
the butt of a few administrators, it is almost certainly a net gain.


Re: FAQ Part 1 typos

2014-11-06 Thread Nick Holland
On 11/06/14 09:35, Nick Permyakov wrote:
 Some typos on
 Section 1.2 - On what systems does OpenBSD run?.
 ...has helped produced a higher-quality code base... should read 
 helped produce (or maybe helped to produce).
 Section 1.8 - What is included with OpenBSD?.
 Note: this will be removed for 5.6 in farvor of NSD and Unbound should 
 read in favor (or did you mean will be removed, in fervor, with NSD 
 and Unbound? ;)).
 And, by the way, isn't it the version 5.6 FAQ? Is BIND removed or not?
 Section 1.11 - Why is/isn't ProductX included?.
 ...project wishes to devote the resources needed to maintaining it... 
 should read needed to maintain it (or maybe needed for maintaining 
 it, but it sounds weird).
 Impact on slower platforms, such as hp300 or VAX would be unacceptable 
 - I think it needs a comma after VAX.
 Best regards,
 Nick Permyakov

fixed, but please keep www/ issues off tech@
tech@ is for code with diffs.



2014-06-26 Thread Nick Holland
On 06/25/14 21:16, Nick Holland wrote: updated (again)

and cvsyncd restarted.  Unfortunately, this was long after the above
note.  *blush*

But yes, there are still issues.


 On 06/25/14 14:51, Bob Beck wrote:
 If you or someone you love runs an anoncvs server, they need to see this.
 As you know we recently added commitid support to cvs, and we had
 you update your cvsync binary.
 Unfortunately, the fix wasn't quite right.  We ran into problems
 with the synching of commitid files. naddy managed to cook
 a correct fix for us. (the fanout machine) has been fixed - again. What you
 need to do is to update your cvsync to the latest one that was
 just committed into ports (cvsync-0.25.0pre0 or later). Remove your
 scanfile (if any).
 Once you do that, re-run cvsync and you should be back in business.
 to check a server do:
 cvs -d log /usr/src/libexec/
 |  less  and see if it has r 1.3
 Thanks, and sorry for the disruption,


2014-06-26 Thread Nick Holland
On 06/26/14 17:18, Stuart Henderson wrote:
 On 2014/06/26 20:20, Christian Weisgerber wrote:
 As everybody noticed, there was another problem.  Please update to
 cvsync-0.25.0pre0p0 for the latest bug fix.  Sorry for all the
 At least the following anoncvs mirrors have this as of now: is updated now, too, and looking
MUCH happier.  Thanks, Naddy and Stuart and Bob!



2014-06-25 Thread Nick Holland updated (again)


On 06/25/14 14:51, Bob Beck wrote:
 If you or someone you love runs an anoncvs server, they need to see this.
 As you know we recently added commitid support to cvs, and we had
 you update your cvsync binary.
 Unfortunately, the fix wasn't quite right.  We ran into problems
 with the synching of commitid files. naddy managed to cook
 a correct fix for us. (the fanout machine) has been fixed - again. What you
 need to do is to update your cvsync to the latest one that was
 just committed into ports (cvsync-0.25.0pre0 or later). Remove your
 scanfile (if any).
 Once you do that, re-run cvsync and you should be back in business.
 to check a server do:
 cvs -d log /usr/src/libexec/
 |  less  and see if it has r 1.3
 Thanks, and sorry for the disruption,


2014-06-06 Thread Nick Holland
On 06/06/14 18:20, Stuart Henderson wrote:
 On 2014/06/07 00:04, Alexander Hall wrote:
 Care to mention the fixed package version, so one knows when it's available
 at the favourite mirror?
 cvsync-0.24.19p3, yes?
 That is correct. There is a -current snapshot package for i386 at
 and probably some mirrors; amd64 should follow shortly.
 For 5.4/i386 there is a package at
 For 5.5/amd64,
 There is a tar of the port directory at which should be able to
 replace an existing port directory on a 5.4 or 5.5 system. should be fixed (using Stuart's packages)
Let me know if there are any issues seen there.


Re: OpenBSD base doesn't build on ARMv7

2013-12-25 Thread Nick Holland
On 12/25/13 19:08, Juan Francisco Cantero Hurtado wrote:
 Hi, I've been seeing the same error for weeks:
 === gnu/usr.bin/cc/libgcc
 Using undefined dynamic variable $* (line 0 of (null))
 Using undefined dynamic variable $* (line 0 of (null))
 /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B 
 /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC -DIN_LIBGCC2 
 -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I.  
 -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline 
 /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsidf.c -o 
 /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B 
 /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC -DIN_LIBGCC2 
 -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I.  
 -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline 
 /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsisf.c -o 
 make: don't know how to make .vis (prerequisite of: _bb_init_func.o 
 Stop in gnu/usr.bin/cc/libgcc
 *** Error 2 in gnu/usr.bin/cc ( 'all')
 *** Error 2 in gnu/usr.bin ( 'all')
 *** Error 2 in gnu ( 'all')
 *** Error 2 in . ( 'all')
 *** Error 2 in /usr/src (Makefile:89 'build')
 Any idea? The full log is here (ignore the messages in spanish, I use a
 script to compile the base):

I just spun a build without issues a couple days ago.  I did have an
issue with making a release, but certainly not what you are seeing
above. (and I haven't looked closely at my release error messages yet)

maybe check your gnu/usr.bin/cc directory for 'M's and 'C's when doing a
checkout against another source?


OpenBSD 5.4 released Nov 1, 2013

2013-11-01 Thread Nick Holland
 instructions in the
   file called INSTALL.i386.  INSTALL.i386 may tell you that you
   need to fetch other files.

6) Just in case, take a peek at:

   This is the page where we talk about the mistakes we made while
   creating the 5.4 release, or the significant bugs we fixed
   post-release which we think our users should have fixes for.
   Patches and workarounds are clearly described there.

Note: If you end up needing to write a raw floppy using Windows,
  you can use fdimage.exe located in the pub/OpenBSD/5.4/tools
  directory to do so.


X.Org has been integrated more closely into the system.  This release
contains X.Org 7.7.  Most of our architectures ship with X.Org, including
amd64, sparc, sparc64 and macppc.  During installation, you can install
X.Org quite easily.  Be sure to try out xdm(1) and see how we have
customized it for OpenBSD.


The OpenBSD ports tree contains automated instructions for building
third party software.  The software has been verified to build and
run on the various OpenBSD architectures.  The 5.4 ports collection,
including many of the distribution files, is included on the 3-CD
set.  Please see the PORTS file for more information.

Note: some of the most popular ports, e.g., the Apache web server
and several X applications, come standard with OpenBSD.  Also, many
popular ports have been pre-compiled for those who do not desire
to build their own binaries (see BINARY PACKAGES, below).


A large number of binary packages are provided.  Please see the PACKAGES
file ( for more details.


The CD-ROMs contain source code for all the subsystems explained
above, and the README (
file explains how to deal with these source files.  For those who
are doing an FTP install, the source code for all four subsystems
can be found in the pub/OpenBSD/5.4/ directory:

xenocara.tar.gz ports.tar.gz   src.tar.gz sys.tar.gz

- THANKS ---

Ports tree and package building by Jasper Lievisse Adriaanse,
Pierre-Emmanuel Andre, Landry Breuil, Michael Erdely, Stuart Henderson,
Peter Hessler, Paul Irofti, Sebastian Reitenbach, Miod Vallat, and
Christian Weisgerber.  System builds by Brian Callahan, Brandon Mercer,
Theo de Raadt and Miod Vallat. X11 builds by Todd Fries and Miod Vallat.
ISO-9660 filesystem layout by Theo de Raadt.

We would like to thank all of the people who sent in bug reports, bug
fixes, donation cheques, and hardware that we use.  We would also like
to thank those who pre-ordered the 5.4 CD-ROM or bought our previous
CD-ROMs.  Those who did not support us financially have still helped
us with our goal of improving the quality of the software.

Our developers are:

Aaron Bieber, Alexander Bluhm, Alexander Hall, Alexandr Shadchin,
Alexandre Ratchov, Anthony J. Bentley, Antoine Jacoutot,
Austin Hook, Benoit Lecocq, Bob Beck, Brad Smith, Brandon Mercer,
Bret Lambert, Brett Mahar, Brian Callahan, Bryan Steele,
Camiel Dobbelaar, Charles Longeau, Chris Cappuccio,
Christian Ehrhardt, Christian Weisgerber, Christiano F. Haesbaert,
Christopher Zimmermann, Claudio Jeker, Damien Miller, Darren Tucker,
David Coppa, David Gwynne, Edd Barrett, Eric Faurot,
Federico G. Schwindt, Florian Obser, Gerhard Roth, Gilles Chehade,
Giovanni Bechis, Gleydson Soares, Gonzalo L. Rodriguez,
Henning Brauer, Ian Darwin, Igor Sobrado, Ingo Schwarze,
Jakob Schlyter, James Turner, Janne Johansson, Jason McIntyre,
Jasper Lievisse Adriaanse, Jeremie Courreges-Anglas, Jeremy Evans,
Jim Razmus II, Joel Sing, Joerg Jung, Jonathan Armani,
Jonathan Gray, Jonathan Matthew, Joshua Elsasser, Joshua Stein,
Kenji Aoyama, Kenneth R Westerback, Kirill Bychkov, Kurt Miller,
Landry Breuil, Laurent Fanis, Lawrence Teo, Luke Tymowski,
Marc Espie, Marco Pfatschbacher, Marcus Glocker, Mark Kettenis,
Mark Lumsden, Mark Uemura, Markus Friedl, Martin Pieuchot,
Martin Reindl, Martynas Venckus, Masao Uebayashi, Mats O Jansson,
Matthew Dempsky, Matthias Kilian, Matthieu Herrb, Michael Erdely,
Mike Belopuhov, Mike Larkin, Miod Vallat, Naoya Kaneko,
Nayden Markatchev, Nicholas Marriott, Nick Holland

Re: Make bioctl(4) print cache policy

2013-10-22 Thread Nick Holland
On 10/22/13 09:47, Mike Belopuhov wrote:
 On 22 October 2013 15:22, Mark Kettenis wrote:
 Diff below makes bioctl(4) print the cache policy for that's currently
 in effect for RAID volumes.  It only prints the state (WB for
 write-back, WT for write-through) if the RAID controller driver fills
 in the details in response to a BIOCVOL ioctl.  This diff adds such
 support to mfi(4).

 # bioctl mfi0
 Volume  Status   Size Device
  mfi0 0 Online72746008576 sd0 RAID1 WB
   0 Online73407820800 1:0.0   noencl HITACHI 
 HUS153073VLS300 A598
   1 Online73407820800 1:1.0   noencl HITACHI 
 HUS153073VLS300 A598


 mpii specs do not use terms write-back or write-through, they rather
 talk about write cache being enabled or disabled.  they obviously
 mean write-back cache.  i believe for the bioctl user it's more
 important to know if actual writes are deferred or not, so i would
 rather say Write Cache Enabled/Disabled or Write Cache On/Off or
 something similar rather then if it's WB or WT.  oterwise people will
 have to look in the man page for what WB or WT stands for and then
 search wikipedia for what does it mean..
 just my 2 cents.

And my 1 cent is that I agree...  I live, work and play with Dell
hardware, been working with their RAID controllers for a lng time,
but I STILL need to think about write through...write back...
lessee... write THROUGH means it is going right to the disk, so not
using the cache, that's bad, I want 'write back'


Re: ntpd jump ahead

2013-09-06 Thread Nick Holland
On 09/06/13 04:50, Stuart Henderson wrote:
 On 2013/09/05 20:03, Barry Grumbine wrote:
 Non-VM use case: The BeagleBone Black has no RTC, so -j could be
 useful for cheap little ARM development boards.
 -s is fine for that (and the same for those of the alix boards with
 no rtc battery, etc).

...unless the machine isn't attached to the network when initially
powered up.

Same goes for any machine with a dead RTC battery that may not have a
good network connection at boot, and/or you don't want to slow the boot
down by 15 seconds if there is no network connection.  This shocks
people, but I often use a computer where there is no network connection.
 Waiting for that 15 second boot delay is annoying.

I like the idea.


Re: /usr/src/etc/mail/aliases formatting

2013-06-23 Thread Nick Holland
On 06/23/13 04:39, MichaƂ Markowski wrote:
 Now, this file is mix of spaces and tabs:
 $ vis -t /cvs/src/etc/mail/aliases
 #\^I$OpenBSD: aliases,v 1.37 2012/10/13 07:42:39 dcoppa Exp $
 This diff provides more consistent formatting with tabs throughout the
 file (sorry for link, but gmail would probably spoil this):
 2013/6/20 Stuart Henderson
 this type of diff is highly subject to bikeshedding ;)

I do believe this would be an annoyance for upgraders who have local
entries in this file, as sysmerge would detect lots of changes, plus the
local changes.  I'm not sure what the benefit would be to those people.

Not saying no...but something to be aware of.


Re: ftpd log address format

2013-05-07 Thread Nick Holland

On 05/07/2013 04:15 PM, Stuart Henderson wrote:

On 2013/05/07 16:09, Ted Unangst wrote:

On Tue, May 07, 2013 at 20:54, Stuart Henderson wrote:

I don't like logging both because there's a not unreasonable chance
the reverse name will be a complete lie, which will just mislead you.

Oh, it doesn't do a forward check of the name it got from reverse
lookup? Yes that's bad.

Well, it kind of does. It does a reverse lookup to get a hostname.
Then it does a forward lookup for that hostname and logs that IP. doh.

Forward lookup? Yes. Forward *check*? No.


*stab stab stab*

lesson: dns can lie.
maybe more accurate: reverse dns is sometimes correct.
There is no promise that forward and reverse DNS provide the same info.

Forward and reverse DNS are like the ski resort, where girls are looking 
for husbands and husbands are looking for girls, but the situation is 
not quite as symmetrical as you might think or hope.
(ok, that's a overly stretched analogy, but I've been wanting to use it 
for a long time!)

log the IP, only the IP, nothing but the IP.
Anything you do with DNS from there is you fooling yourself, and 
hopefully you understand what it means.


Re: ftpd log address format

2013-05-05 Thread Nick Holland
On 05/04/13 01:57, Ted Unangst wrote:
 On Sat, May 04, 2013 at 07:26, Martijn van Duren wrote:
 For a lot of cases this isn't a problem. But there are a couple of
 instances where the domain name resolves to something a little to
 generic to be useful to determine it's origin and hence I'm not able to
 decide if it's a legit connection or not, let alone being able to place
 it in my firewall.
 To fix this for myself I made this minor patch to retrieve the ip
 address instead of the the reverse lookup. This appears to be the same
 behavior as sshd shows.
 I think this is wise. Reverse lookups are not really useful imo. If
 someone cares, they can always do them later.

regarding the concept, not the patch...agreed.

I have OFTEN wished I had the raw IP address in a log, I've rarely (I
want to say never) wished I had a reverse DNS lookup.


Re: [UPDATE] www/papers/index.html - Eric's OpenSMTPd presentation

2013-04-02 Thread Nick Holland

On 04/02/2013 09:20 AM, Jiri B wrote:

Index: index.html
RCS file: /cvs/www/papers/index.html,v
retrieving revision 1.166
diff -u -p -r1.166 index.html
--- index.html  23 Mar 2013 17:56:07 -  1.166
+++ index.html  2 Apr 2013 13:01:44 -
@@ -18,6 +18,13 @@
  h3Presentations: AsiaBSDCon 2013/h3
  font color=#009000strong
+a href=;OpenSMTPD: We 
+Eric Faurot
+font color=#009000strong
  a href=asiabsdcon2013/phessler-bgp-spamd-presentation.pdfUsing BGP for Realtime 
import and export of OpenBSD SPAMD entries/a,
  Peter Hessler

good presentation, and worth adding here, I think, but took me quite a 
while (and an incompatible browser -- IE!) to figure out how to move 
around in it...  Assuming I'm not the last person to see a presentation 
like this, a note to use the arrow keys to negotiate the pages would 
probably be good.


Re: goodbye to some isa devices

2013-03-27 Thread Nick Holland
my thoughts inline...

On 03/26/13 05:20, Ted Unangst wrote:
 These isa devs are already disabled and not particularly popular among
 our users.  affected: tcic, sea, wds, eg, el
 Index: arch/i386/conf/GENERIC
 RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
 -pcmcia* at tcic?

I really can't comment.  Haven't had much luck with PCMCIA lately.
Haven't cared enough to,

 -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers

this driver doesn't work anyway, or at least it didn't, somewhere over
ten years ago when I last tried.  If it did work, you wouldn't want it
to.  It was intended for things like scanners and other really slow things.

 -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 
 -#wds1at isa? port 0x358 irq 11 drq 5

I've never seen one of these.  That says something.  Not sure what.

 -eg0  at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet

This is an incredibly rare, huge, power hungry NIC.  I've got one, I
think.  Never tested it.  It came from the store I worked at, we tried
to sell them for $600-$700 each, back in the mid 1980s.  The one I think
I have is the store demo, we never sold any.  It was kinda cool in that
it was a 16 bit card with its own 80186 CPU on it...but for use, it is

 -el0  at isa? disable port 0x300 irq 9# 3C501 ethernet

This is probably the worst Ethernet card ever built and sold.
Apparently, it has ONE buffer, which can be receiving data, sending
data, or dropping data when switching between the two modes.

IF anyone in the U.S. is running a 3c501 or a 3c505 and is upset with
this being removed. I'll send you a 3c509B.  You will be very happy with it.

None of this stuff will be missed by users.  The only question would be
the tcic, I don't know what it would be in.  I suspect it would be a
non-issue, it's probably old enough to be in laptops which were rarely
expanded to 32M RAM.

There is a lot of ISA stuff I'd object to removing from the kernel; none
of this is it.  I'm entirely ok with this stuff going...


Re: Fixing a phrase in /stable.html

2013-02-18 Thread Nick Holland
On 02/17/13 04:54, Jason McIntyre wrote:
 On Sun, Feb 17, 2013 at 01:29:00PM +0400, Nick Permyakov wrote:
 I might be nitpicking, but the sentence This will take awhile... at 
 the bottom of doesn't seem very 
 grammatical to me. I'd suggest fixing it to read ...take a while
 Best regards,
 Nick Permyakov
 i thought it sounded strange too, so i looked it up. from collins
   awhile: Awhile means for a short time. It is more commonly
   spelled `a while', which is considered more correct, especially
   in British English.
 so i don;t think there's anything wrong with it, as such. having said
 that, it's written in the context of a make build. i wonder whether the
 author really wanted to suggest a short time ;)

a while/awhile means a short time? wow.  I've always used it as
meaning a long time.  'course, I usually say it with a sarcastic tone,
so maybe it's the sarcasm that gets the point across.

I've changed it to This will take some time. Depending on the speed of
the system, it may take less than an hour to a week or more.


Re: Fixing a phrase in /stable.html

2013-02-18 Thread Nick Holland
On 02/18/13 19:51, Chris Cappuccio wrote:
 Marc Espie [] wrote:
 This seems like a disturbing trend to me.
 are we going to turn www into a dumbed-down international english slang ? ...
 Yeah, we need some more translations of www. What should we call the
 mix of hillbilly, valley girl, inner-city slang, and various grunts?

Nick@'s writing style
SOMEONE had to say it!


Re: CVS changeset that fixed multiple NIC issue in 5.2-CURRENT?

2012-12-12 Thread Nick Holland
On 12/12/2012 02:37 PM, Robbert Kouprie wrote:
 As this is going to be a production system, I would prefer to run STABLE
 + this specific fix.

You will, I think, be better off running -current (which is supported)
than a Frankenstein monster with an inaccurate name (which is not


Re: [patch] -H flag for grep.

2011-02-22 Thread Nick Holland
On 02/22/11 16:47, Stuart Henderson wrote:
 On 2011/02/22 01:08, patrick keshishian wrote:
  find . -name '*.c' -exec awk '/bla/ {print FILENAME $0}'
 my that's awkward.

d'oh.  I missed that.  And I thought I was good at the bad pun.


Re: softraid clarification in manpage

2011-01-28 Thread Nick Holland
On 01/27/11 17:17, Amit Kulkarni wrote:
 That's a much better suggestion, also keeping in mind what jmc@ said.
 I will send a unified diff against the following file over the
 But first I will tear down the mirror and document everything from scratch.
 Thanks for your feedback

unless you write many times as fast as I do (actually, most people do),
you need a lot more time than that.

there's a softraid FAQ entry I've been working on for a while that's on
hold until certain people are happier with the state of softraid and


Re: softraid cleanup

2010-11-07 Thread Nick Holland
On 11/02/10 15:56, Marco Peereboom wrote:
 Got tons of great test results but still not an independent RAID 1
 rebuild.  I really want to commit this but I won't until someone else
 besides me tests this.
 On Thu, Oct 21, 2010 at 02:17:58PM -0500, Marco Peereboom wrote:

Sun E250 (sparc64), built softraid RAID1 pair, installed kernel with
this patch, removed one drive from the RAID set, replaced drive with a
different drive, rebuilt RAID1 to that new drive.

No issues seen.


 On Wed, Oct 20, 2010 at 08:47:00PM -0500, Marco Peereboom wrote:
  On Thu, Sep 30, 2010 at 03:35:33AM +0200, Tobias Ulmer wrote:
   I got this after a while:
   panic: softraid0: sr_crypto_finish_io
   No serial, so there's no more info. You know where to find me
  new diff that should fix all them issues.
  please test, especially raid 1 including rebuild and stuff.
  Index: dev/softraid.c
  RCS file: /cvs/src/sys/dev/softraid.c,v
  retrieving revision 1.215
  diff -u -p -r1.215 softraid.c
  --- dev/softraid.c 12 Oct 2010 00:53:32 -  1.215
  +++ dev/softraid.c 21 Oct 2010 01:36:32 -
  @@ -126,6 +126,7 @@ void   sr_rebuild(void *);
   void  sr_rebuild_thread(void *);
   void  sr_roam_chunks(struct sr_discipline *);
   int   sr_chunk_in_use(struct sr_softc *, dev_t);
  +void  sr_startwu_callback(void *, void *);
   /* don't include these on RAMDISK */
   #ifndef SMALL_KERNEL
  @@ -1806,6 +1807,8 @@ sr_wu_put(struct sr_workunit *wu)
 wu-swu_fake = 0;
 wu-swu_flags = 0;
  +  if (wu-swu_cb_active == 1)
  +  panic(%s: sr_wu_put, DEVNAME(sd-sd_sc));
 while ((ccb = TAILQ_FIRST(wu-swu_ccb)) != NULL) {
 TAILQ_REMOVE(wu-swu_ccb, ccb, ccb_link);
  @@ -2563,6 +2566,9 @@ sr_hotspare_rebuild(struct sr_discipline
 busy = 0;
 s = splbio();
  +  if (wu-swu_cb_active == 1)
  +  panic(%s: sr_hotspare_rebuild,
  +  DEVNAME(sd-sd_sc));
 TAILQ_FOREACH(wu, sd-sd_wu_pendq, swu_link) {
 TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
 if (ccb-ccb_target == chunk_no)
  @@ -2816,6 +2822,11 @@ sr_ioctl_createraid(struct sr_softc *sc,
 sd = malloc(sizeof(struct sr_discipline), M_DEVBUF, M_WAITOK | M_ZERO);
 sd-sd_sc = sc;
  +  sd-sd_workq = workq_create(srdis, 1, IPL_BIO);
  +  if (sd-sd_workq == NULL) {
  +  printf(%s: could not create workq\n);
  +  goto unwind;
  +  }
 if (sr_discipline_init(sd, bc-bc_level)) {
 printf(%s: could not initialize discipline\n, DEVNAME(sc));
 goto unwind;
  @@ -3407,6 +3418,9 @@ sr_discipline_shutdown(struct sr_discipl
 sr_chunks_unwind(sc, sd-sd_vol.sv_chunk_list);
  +  if (sd-sd_workq)
  +  workq_destroy(sd-sd_workq);
 if (sd)
  @@ -3625,10 +3639,29 @@ sr_raid_sync(struct sr_workunit *wu)
  +sr_startwu_callback(void *arg1, void *arg2)
  +  struct sr_discipline*sd = arg1;
  +  struct sr_workunit  *wu = arg2;
  +  struct sr_ccb   *ccb;
  +  int s;
  +  s = splbio();
  +  if (wu-swu_cb_active == 1)
  +  panic(%s: sr_startwu_callback, DEVNAME(sd-sd_sc));
  +  wu-swu_cb_active = 1;
  +  TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link)
  +  VOP_STRATEGY(ccb-ccb_buf);
  +  wu-swu_cb_active = 0;
  +  splx(s);
   sr_raid_startwu(struct sr_workunit *wu)
 struct sr_discipline*sd = wu-swu_dis;
  -  struct sr_ccb   *ccb;
  @@ -3643,9 +3676,8 @@ sr_raid_startwu(struct sr_workunit *wu)
 TAILQ_INSERT_TAIL(sd-sd_wu_pendq, wu, swu_link);
 /* start all individual ios */
  -  TAILQ_FOREACH(ccb, wu-swu_ccb, ccb_link) {
  -  VOP_STRATEGY(ccb-ccb_buf);
  -  }
  +  workq_queue_task(sd-sd_workq, wu-swu_wqt, 0, sr_startwu_callback,
  +  sd, wu);
  Index: dev/softraid_crypto.c
  RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
  retrieving revision 1.57
  diff -u -p -r1.57 softraid_crypto.c
  --- dev/softraid_crypto.c  27 Sep 2010 19:49:43 -  1.57
  +++ dev/softraid_crypto.c  5 Oct 2010 20:49:24 -
  @@ -164,11 +164,11 @@ sr_crypto_create(struct sr_discipline *s
 } else if (sr_crypto_get_kdf(bc, sd))
 goto done;
 /* Passphrase volumes cannot be automatically assembled. */
 if (!(bc-bc_flags  BIOC_SCNOAUTOASSEMBLE)  bc-bc_key_disk == NODEV)
 goto done;
 strlcpy(sd-sd_name, CRYPTO, sizeof(sd-sd_name));

Re: snapshot install, disklabel quirks

2010-08-17 Thread Nick Holland
On 08/17/10 03:24, Thomas de Grivel wrote:
 For the record, i met a couple problems with the snapshot install
   - when selecting custom layout of an existing OpenBSD partition, the 
 disklabel utility had kept the mount points from the auto layout, and 
 refused that i set them, what it thought to be twice.
   - wifi essid and key would not be configurable but asked for IP 
 configuration, but i guess this is expected and that there is no support 
 for wireless installation.
 The rest of the install went real smooth, as usual.

Snapshot date?


Re: faq14.html

2010-03-08 Thread Nick Holland
J.C. Roberts wrote:
 Initially, I just wanted to fix the use create typo, but decided to 
 make it shorter, more accurate, and more clear in the process.

btw: this is a good type of diff.
Too often, people will spot the typo, correct the typo, and leave the
rest of the section poorly worded and overly verbose.


 Index: faq14.html
 RCS file: /cvs/www/faq/faq14.html,v
 retrieving revision 1.198
 diff -N -u -p faq14.html
 --- faq14.html4 Mar 2010 01:14:13 -   1.198
 +++ faq14.html7 Mar 2010 22:17:07 -
 @@ -2274,10 +2274,9 @@ You will, of course, be unable to test your work until
  USB bootable system.
  libGoing from IDE to USB interfaces:/b
 -As the media will be readable and writable from both USB and IDE
 -adapters, you can use create the media for booting in an IDE adapter but
 -maintain it in a USB adapter on a different machine (or the other way
 +Since flash media can be readable and writable through USB, IDE and 
 +other adapters, you can create bootable media with one type of adapter
 +but maintain or use it with another type of adapter.
  libMixing OpenBSD and other partitions on one device:/b
  OpenBSD treats the flash disk as any other disk so one can use 

Re: Add rEFIt bootloader to FAQ4

2010-03-07 Thread Nick Holland
Lars Nooden wrote:
 rEFIt can be used with OpenBSD, especially when dual booting OS X, or when 
 triple booting OS X and Linux.

Good suggestion, just added it.
two issues about your diff, however:
1) gmail mangled it.  (and oddly.  I'm sure they have a reason for
what they did to it, but I'm at a loss as to what it would be).
2) the translations are handled separately -- while the effort is
appreciated, if we commit them, we screw up the translators.  Thank
goodness...I'm hopefully monolingual, if I had to make changes and
write new material in ten languages, we'll, I guess I'd have more free
time. :)


 Index: faq4.html
 RCS file: /cvs/www/faq/faq4.html,v
 retrieving revision 1.294
 diff -u -p -r1.294 faq4.html
 --- faq4.html 12 Feb 2010 03:12:21 -  1.294
 +++ faq4.html 5 Mar 2010 19:47:20 -
 @@ -2554,7 +2554,8 @@ Website for more current information.  D
   Some other bootloaders OpenBSD users have used successfully include
   a href=;GAG/a,
 -a href=;The Ranish Partition Manager/a
 +a href=;The Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   and a href=;GRUB/a.
 Index: ./cs/faq4.html
 RCS file: /cvs/www/faq/cs/faq4.html,v
 retrieving revision 1.33
 diff -u -p -r1.33 faq4.html
 --- ./cs/faq4.html28 Feb 2010 08:37:46 -  1.33
 +++ ./cs/faq4.html5 Mar 2010 19:47:21 -
 @@ -2517,7 +2517,8 @@ a web str??nku pro aktu??ln??j infor
   N??kter?? dal boot loadery, kter?? OpenBSD u??ivatel?? ??spn?? 
 pou??ili v??etn??
   a href=;GAG/a,
 -a href=;Ranish Partition Manager/a
 +a href=;Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   a a href=;GRUB/a.
 Index: ./de/faq4.html
 RCS file: /cvs/www/faq/de/faq4.html,v
 retrieving revision 1.125
 diff -u -p -r1.125 faq4.html
 --- ./de/faq4.html1 Dec 2008 07:52:51 -   1.125
 +++ ./de/faq4.html5 Mar 2010 19:47:22 -
 @@ -2109,7 +2109,8 @@ Zu einigen anderen Bootloadern, die von
   eingesetzt worden sind, geh?ren
   a href=;GAG/a,
 -a href=;The Ranish Partition Manager/a
 +a href=;The Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   und a href=;GRUB/a.
 Index: ./es/faq4.html
 RCS file: /cvs/www/faq/es/faq4.html,v
 retrieving revision 1.77
 diff -u -p -r1.77 faq4.html
 --- ./es/faq4.html11 Sep 2004 08:20:12 -  1.77
 +++ ./es/faq4.html5 Mar 2010 19:47:24 -
 @@ -2176,7 +2176,8 @@ Otros cargadores de arranque que se han
   OpenBSD son:
   a href=;GAG/a,
 -a href=;The Ranish Partition Manager/a
 +a href=;The Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   y a href=;GRUB/a.
 Index: ./fr/faq4.html
 RCS file: /cvs/www/faq/fr/faq4.html,v
 retrieving revision 1.95
 diff -u -p -r1.95 faq4.html
 --- ./fr/faq4.html16 Feb 2010 09:19:53 -  1.95
 +++ ./fr/faq4.html5 Mar 2010 19:47:25 -
 @@ -2663,7 +2663,8 @@ modifi?s.
   D'autres utilisateurs de chargeurs de d?marrage OpenBSD ont inclus avec
   a href=;GAG/a,
 -a href=;The Ranish Partition Manager/a
 +a href=;The Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   et a href=;GRUB/a.
 Index: ./hu/faq4.html
 RCS file: /cvs/www/faq/hu/faq4.html,v
 retrieving revision 1.29
 diff -u -p -r1.29 faq4.html
 --- ./hu/faq4.html10 May 2006 21:50:16 -  1.29
 +++ ./hu/faq4.html5 Mar 2010 19:47:26 -
 @@ -2085,7 +2085,8 @@ arra, hogy a m?sodik merevlemezr?l t?lts
   Az OpenBSD felhaszn?l?k sok egy?b
   rendszerbet?lt?t haszn?lnak sikeresen, mint pl. a a
 -a href=;The Ranish Partition Manager/a
 +a href=;The Ranish Partition Manager/a,
 +a href=;rEFIt/a,
   ?s a a href=;GRUB/a.
 Index: ./nl/faq4.html
 RCS file: 

Re: Clearing the console each time a user logs out

2009-07-17 Thread Nick Holland
Stuart Henderson wrote:
 I think I looked at this before then forgot about it,
 I'm in two minds whether to update it, or just remove the faq entry,
 because it doesn't really work all that well (doesn't clear the scrollback)
 and it forces serial ports to have control sequences that might confuse
 some terminals...
 Any thoughts?

I'm thinking remove.
There are probably platform-based quirks that all the proposed changes
don't deal with (i.e., sun), the scroll-back is an easily forgotten issue,
remote terminals, etc.

Let's just remove it.


 In gmane.os.openbsd.misc, Mark Zimmerman wrote:
 On Fri, Jul 10, 2009 at 08:48:12PM +0200, Olivier Regnier wrote:
 I have already modified the file gettytab with these lines:
 P:Pc:Pc   console:\
 This does not work ? An idea ?

 The FAQ entry for this has been wrong for a few releases now. Try


 Assuming /etc/ttys has this for the console:

 console /usr/libexec/getty std.9600   vt220   off secure