Website (and mirror) maintenance: cvsweb.openbsd.org, man.openbsd.org
Hello, I tell people they shouldn't be posting to tech@ without a diff, so ... I'm announcing this "diff", which will "applied" July 17 at around 7:00am EDT, and hopefully will be reverted by 7:00pm. === RCS file: /home/nick/mirrorsystems-currently-running.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- nick/mirrorsystems-currently-running.txt2022/04/10 16:31:30 1.2 +++ nick/mirrorsystems-currently-running.txt2022/07/16 00:58:55 1.3 @@ -74,7 +74,8 @@ -man.openbsd.org -cvsweb.openbsd.org -openbsd.cs.toronto.edu -obsdacvs.cs.toronto.edu Or in English: Due to power maintenance, the following systems are expected be down 7:00am to 7:00pm EST on Sunday July 17: man.openbsd.org cvsweb.openbsd.org openbsd.cs.toronto.edu obsdacvs.cs.toronto.edu Systems should come back up when the power work is completed, I'll be monitoring and verifying. Nick.
dmesg submitting tool
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 dm...@openbsd.org
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 dm...@openbsd.org or
rejected
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 dmesg.egoslike.us
You can download the senddmesg script:
$ sftp dm...@dmesg.egoslike.us:/outgoing/senddmesg
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.
Nick.
Maintenance: (man|cvsweb).openbsd.org, (openbsd|obsdacvs).cs.toronto.edu
hi. 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. * man.openbsd.org * cvsweb.openbsd.org * obsdacvs.cs.toronto.edu * openbsd.cs.toronto.edu Nick.
/etc/daily : flexible df output
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"
+fi
+
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
else
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"
+fi
+
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
else
Re: right/ tzdata files (was ports@ Re: (Mozilla) Thunderbird time zone issue)
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. >> > >> > https://data.iana.org/time-zones/theory.html#leapsec >> > >> > 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. Nick.
Re: small detail on faq current upgrade guide.
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. Nick.
Re: request for testing: patch for boot loader out of mem
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.
Nick.
/home/nick $ dmesg|head
OpenBSD 6.4-current (GENERIC.MP) #510: Thu Dec 13 06:20:42 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 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, obsdacvs.cs.toronto.edu, man.openbsd.org cvsweb.openbsd.org
Hiya. 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 * obsdacvs.cs.toronto.edu * man.openbsd.org * cvsweb.openbsd.org Thanks for your patience! Nick.
acme-client doc diff
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 "example.com", but in
acme-client(1), it's "www.example.com". Not interchangeable, so
standardize on "example.com".
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:
https://holland-consulting.net/acme-client.diff
Nick.
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 { secure.example.com }
# domain key "/etc/ssl/private/example.com.key"
# domain certificate "/etc/ssl/example.com.crt"
-# domain chain certificate "/etc/ssl/example.com.chain.pem"
+# domain full chain certificate "/etc/ssl/example.com.fullchain.pem"
# 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).
.Sh EXAMPLES
+To initialize a new account (host) key:
+.Pp
+.Dl # acme-client -vAD example.com
+.Pp
+
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:
.Pp
-.Dl # acme-client -vD www.example.com
+.Dl # acme-client -vD example.com
.Pp
A daily
.Xr cron 8
@@ -110,7 +115,7 @@
.Bd -literal -offset indent
#! /bin/sh
-acme-client www.example.com
+acme-client example.com
if [ $? -eq 0 ]
then
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 -
1.8
+++ 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
.Sx AUTHORITIES
@@ -151,8 +157,28 @@
alternative names { secure.example.com www.example.com }
domain key "/etc/ssl/private/example.com.key"
domain certificate "/etc/ssl/example.com.crt"
+ domain full chain certificate "/etc/ssl/example.com.fullchain.pem"
sign with letsencrypt
challengedir "/var/www/acme"
+}
+.Ed
+.Pp
+An
+.Xr httpd.conf 5
+server declaration to use that certificate looks like this:
+.Bd -literal -offset indent
+server "example.com" {
+alias "www.example.com"
+alias "secure.example.com"
+listen on $ext_addr port 80
+listen on $ext_addr tls port 443
+tls certificate "/etc/ssl/example.com.fullchain.pem"
+tls key "/etc/ssl/private/example.com.key"
+location "/.well-known/acme-challenge/*" {
+root "/acme"
+root strip 2
+}
+root "/htdocs"
}
.Ed
.Sh FILES
Re: [WWW] Reverse chronological order for faq/current.html
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. Nick.
Mirror downage: openbsd.cs.toronto.edu, obsdacvs.cs.toronto.edu, man.openbsd.org, cvsweb.openbsd.org
Hi. 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: * openbsd.cs.toronto.edu * obsdacvs.cs.toronto.edu * http://cvsweb.openbsd.org * http://man.openbsd.org Sorry for any inconvenience this might cause. Nick.
University of Toronto Mirror upcoming outages
Hi, A heads-up for users of the University of Toronto mirror (openbsd.cs.toronto.edu): 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. Thanks! Nick.
Re: Invalid HTML entities in upgrade57.html
On 09/25/15 12:57, Kevin Zhang wrote:
> Using >, & in raw text is invalid HTML.
Not according to validator.w3.org.
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.
Nick.
(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
> cd ${RELEASEPATH}
> -rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
> +rm /obsd ; ln /bsd /obsd cp bsd.mp /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
> cd ${RELEASEPATH}
> -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 bsd.mp /
>
> (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
On 07/07/15 06:34, Pavel Plamenov wrote: Updated patch, paying more attention to style. Index: plus52.html ... yep, I like those. Thanks! Nick. === 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus52.html; 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus53.html; 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus54.html; 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus55.html; 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus56.html; 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 html head -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 OpenBSD. link rel=canonical href=http://www.openbsd.org/plus57.html; 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 html head -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
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: https://xkcd.com/538/ 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. Nick. Original Message From: ertetlen barmok ertetlenbar...@safe-mail.net Apparently from: owner-tech+m42...@openbsd.org To: tech@openbsd.org Subject: RAM encryption and key storing in CPU Date: Sat, 23 May 2015 05:15:47 -0400 Hello, == Problem: 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: https://citp.princeton.edu/research/memory/media/ == Solution: 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: https://www1.informatik.uni-erlangen.de/tresor *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
On 06/06/15 11:35, Todd Mortimer wrote: Hi tech@ It seems that this question comes up frequently enough that people might be tired of answering it. Not sure if this is the right spot in the FAQ to put this, or even if this is something that people want included in there at all. Rejections, corrections and bikeshedding welcome. Cheers, Todd I'm not against this, but lemme see what I can come up with, got a few additional points I'd like made. Nick. 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 card?/a + lia href=#blobs12.1.9 - Does OpenBSD include any binary-only device drivers (blobs)?/a /ul 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 tasks. Your results may vary widely depending on the task you have to accomplish. + +h3 id=blobs12.1.9 - Does OpenBSD include any binary-only device drivers (blobs)?/h3 + +No. The source code for all of the device drivers in the OpenBSD kernel is +available in a href=http://www.openbsd.org/anoncvs.html;CVS/a. OpenBSD has +rejected binary device drivers (a.k.a. blobs) for many years, and this was even +the subject of the a href=http://www.openbsd.org/lyrics.html#39;3.9 release song/a, +which was released in 2006. + +p +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 device +and includes the +a href=http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/fw_update.1;fw_update(1)/a +utility, which can fetch non-free firmware from the Internet if the vendor has +made it available. + +p +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. If +OpenBSD does not yet support that hardware, then users can submit new device drivers +or patches to the a href=http://www.openbsd.org/faq/faq2.html#MailLists;tech/a +mailing list. h2 id=alpha12.2 - DEC Alpha/h2 [nothing yet]
Re: [PATCH] FTP as an install method is no more
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!
Nick.
Regards,
Raf
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
HTTP/FTP/a/font/h3
-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
/ul
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.
/ul
-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?
ul
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
/pre/td/tr/table
p
@@ -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.
p
a name=Multiple/a
Re: [EXTERNAL] Re: Mention pkg-readmes in FAQ
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. :) Nick. -Original Message- From: owner-t...@openbsd.org [mailto:owner-t...@openbsd.org] On Behalf Of Stuart Henderson Sent: Saturday, April 25, 2015 10:07 AM To: trondd Cc: tech@openbsd.org 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: blockquotepre
Re: Do you need/prefer the non-DUID option in the installer?
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 now. 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 setup. 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 ride. 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. Nick.
Re: FAQ 14.9: installboot example parameters reversed
On 02/26/15 05:44, Rolf Sommerhalder wrote: Hi, While salvaging a CompactFlash with a corrupt partition table, I noticed that the example in http://www.openbsd.org/faq/faq14.html#InstBoot 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 or: 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 Thanks, Rolf 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. Nick.
Re: faq: remove references to aucat -M option
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? 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. Nick. 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; /pre/blockquote -It shows three MIDI ports, corresponding to: +It shows three MIDI ports, known by +a href=http://www.openbsd.org/cgi-bin/man.cgi?query=sndio;sndio(7)/a +as: ul -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 /ul -These devices are known by -a href=http://www.openbsd.org/cgi-bin/man.cgi?query=sndio;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 layers. To test your MIDI keyboard, you can use the a href=http://www.openbsd.org/cgi-bin/man.cgi?query=hexdumpamp;sektion=1;hexdump(1)/a utility to display MIDI data you're playing on it: blockquotepre -$ strongaucat -Mq rmidi/1 -o - | hexdump -e '1/1 %02x\n'/strong +$ stronghexdump -e '1/1 %02x\n' lt; /dev/rmidi0/strong 90 3c 71 @@ -835,14 +837,11 @@ The output of the keyboard can be connec synthesizer, as follows: blockquotepre -$ strongaucat -M -q rmidi/0 -q rmidi/1/strong +$ strongcat -u lt; /dev/rmidi0 gt; /dev/rmidi1/strong /pre/blockquote Now you can hear on the synthesizer what you're playing on the MIDI keyboard. -Refer to the -a href=http://www.openbsd.org/cgi-bin/man.cgi?query=aucatamp;sektion=1;aucat(1)/a -manual page for further information. !-- h3Playing, recording MIDI sequences/h3 -- @@ -854,6 +853,19 @@ is as easy as: blockquotepre $ strongmidiplay -f rmidi/0 file.mid/strong +/pre/blockquote + +p +The +a href=http://www.openbsd.org/cgi-bin/man.cgi?query=sndiod;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: + +blockquotepre +$ strongmidiplay -f midithru/0 file.mid/strong /pre/blockquote p
Re: [DIFF] /etc/rc: gracefully shut down base daemons too
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 mean...like 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. Nick.
Re: faq diff: kerberos
On 11/25/14 18:45, J Sisson wrote: Hi, kerberos was moved to ports, but the docs still link to kerberos(8): http://www.openbsd.org/faq/faq10.html#YP_secure Does the following diff make sense? (Apologies in advance if gmail mangles the diff, or if the diff needs to be generated with different options). --- 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=http://www.openbsd.org/cgi-bin/man.cgi?query=kerberosamp;sektion=8; -kerberos(8)/a authentication. +kerberos authentication (available from ports). p a name=YP_server/a good spotting, but I'd prefer to remove the kerberos reference all together (and I did). Nick.
Re: rwho on OpenBSD 5.6
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. wow. 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. Nick.
Re: FAQ Part 1 typos
On 11/06/14 09:35, Nick Permyakov wrote: Hi, Some typos on http://www.openbsd.org/faq/faq1.html 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. Nick.
Re: ANONCVS MIRROR MAINTAINERS.. YOU NEED TO READ THIS!
On 06/25/14 21:16, Nick Holland wrote: openbsd.cs.toronto.edu updated (again) and cvsyncd restarted. Unfortunately, this was long after the above note. *blush* But yes, there are still issues. Nick. 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. anoncvs.ca (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 anon...@yourserver.org:/cvs log /usr/src/libexec/ld.so/malloc.c | less and see if it has r 1.3 Thanks, and sorry for the disruption, -Bob
Re: ANONCVS MIRROR MAINTAINERS.. YOU NEED TO READ THIS!
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 inconvenience. At least the following anoncvs mirrors have this as of now: anon...@anoncvs.spacehopper.org:/cvs anon...@anoncvs.usa.openbsd.org:/cvs anon...@anoncvs.ca.openbsd.org:/cvs anon...@anoncvs.cs.toronto.edu:/cvs anon...@openbsd.cs.toronto.edu:/cvs is updated now, too, and looking MUCH happier. Thanks, Naddy and Stuart and Bob! Nick.
Re: ANONCVS MIRROR MAINTAINERS.. YOU NEED TO READ THIS!
openbsd.cs.toronto.edu updated (again) Nick. 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. anoncvs.ca (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 anon...@yourserver.org:/cvs log /usr/src/libexec/ld.so/malloc.c | less and see if it has r 1.3 Thanks, and sorry for the disruption, -Bob
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
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 http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/cvsync-0.24.19p3.tgz and probably some mirrors; amd64 should follow shortly. For 5.4/i386 there is a package at http://ftp.obsd.si/pub/OpenBSD-unofficial/5.4-stable/i386/cvsync-0.24.19p3.tgz For 5.5/amd64, http://spacehopper.org/mirrors/cvsync-0.24.19p3.tgz There is a tar of the port directory at http://spacehopper.org/mirrors/cvsync-port.tgz which should be able to replace an existing port directory on a 5.4 or 5.5 system. openbsd.cs.toronto.edu should be fixed (using Stuart's packages) Let me know if there are any issues seen there. Nick.
Re: OpenBSD base doesn't build on ARMv7
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 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -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 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=/usr -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsidf.c -o floatunsidf.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 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -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 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=/usr -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsisf.c -o floatunsisf.o make: don't know how to make .vis (prerequisite of: _bb_init_func.o _dvmd_tls.o) Stop in gnu/usr.bin/cc/libgcc *** Error 2 in gnu/usr.bin/cc (bsd.subdir.mk:48 'all') *** Error 2 in gnu/usr.bin (bsd.subdir.mk:48 'all') *** Error 2 in gnu (bsd.subdir.mk:48 'all') *** Error 2 in . (bsd.subdir.mk:48 '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): http://juanfra.info/bl/openbsd-arm-201312/error_base.log 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? Nick
OpenBSD 5.4 released Nov 1, 2013
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: http://www.OpenBSD.org/errata.html 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 FOR MOST ARCHITECTURES - 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. - PORTS TREE --- 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). - BINARY PACKAGES WE PROVIDE --- A large number of binary packages are provided. Please see the PACKAGES file (ftp://ftp.OpenBSD.org/pub/OpenBSD/5.4/PACKAGES) for more details. - SYSTEM SOURCE CODE --- The CD-ROMs contain source code for all the subsystems explained above, and the README (ftp://ftp.OpenBSD.org/pub/OpenBSD/5.4/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
On 10/22/13 09:47, Mike Belopuhov wrote: On 22 October 2013 15:22, Mark Kettenis mark.kette...@xs4all.nl 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 ok? 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' Nick.
Re: ntpd jump ahead
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. Nick.
Re: /usr/src/etc/mail/aliases formatting
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): http://mspanc.one.pl/etc_mail_aliases.diff P.S. 2013/6/20 Stuart Henderson s...@spacehopper.org: 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. Nick.
Re: ftpd log address format
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. Wow. *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. Nick.
Re: ftpd log address format
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. Nick.
Re: [UPDATE] www/papers/index.html - Eric's OpenSMTPd presentation
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 blockquote font color=#009000strong +a href=https://poolp.org/~eric/asiabsdcon2013-smtpd/;OpenSMTPD: We deliver!/a, +Eric Faurot +/strong/fontbr +/blockquote + +blockquote +font color=#009000strong a href=asiabsdcon2013/phessler-bgp-spamd-presentation.pdfUsing BGP for Realtime import and export of OpenBSD SPAMD entries/a, Peter Hessler /strong/fontbr 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. Nick.
Re: goodbye to some isa devices
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, uh..care. -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 controllers -#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 uninteresting. -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... Nick.
Re: Fixing a phrase in /stable.html
On 02/17/13 04:54, Jason McIntyre wrote: On Sun, Feb 17, 2013 at 01:29:00PM +0400, Nick Permyakov wrote: Hi, I might be nitpicking, but the sentence This will take awhile... at the bottom of http://www.openbsd.org/stable.html 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 cobuild: 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 ;) jmc 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. Nick.
Re: Fixing a phrase in /stable.html
On 02/18/13 19:51, Chris Cappuccio wrote: Marc Espie [es...@nerim.net] 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! Nick.
Re: CVS changeset that fixed multiple NIC issue in 5.2-CURRENT?
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 supported). Nick.
Re: [patch] -H flag for grep.
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.
^^^
*groan*
d'oh. I missed that. And I thought I was good at the bad pun.
Nick.
Re: softraid clarification in manpage
On 01/27/11 17:17, Amit Kulkarni wrote: thib@, 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 weekend. http://www.openbsd.org/cgi-bin/cvsweb/www/faq/faq14.html 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 diskmap. Nick.
Re: softraid cleanup
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.
Nick.
anyone?
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);
sr_ccb_put(ccb);
@@ -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;
SLIST_INIT(sd-sd_meta_opt);
+ 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)
sr_discipline_free(sd);
@@ -3625,10 +3639,29 @@ sr_raid_sync(struct sr_workunit *wu)
}
void
+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);
+}
+
+void
sr_raid_startwu(struct sr_workunit *wu)
{
struct sr_discipline*sd = wu-swu_dis;
- struct sr_ccb *ccb;
splassert(IPL_BIO);
@@ -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);
}
void
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
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. Platform? Snapshot date? Nick.
Re: faq14.html
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. committed. 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. Nick. 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 -around). +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
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. :) Nick. 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 p Some other bootloaders OpenBSD users have used successfully include a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, and a href=http://www.gnu.org/software/grub/;GRUB/a. p 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 p N??kter?? dal boot loadery, kter?? OpenBSD u??ivatel?? ??spn?? pou??ili v??etn?? a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;Ranish Partition Manager/a +a href=http://www.ranish.com/part/;Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, a a href=http://www.gnu.org/software/grub/;GRUB/a. p 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=http://gag.sourceforge.net/;GAG/a, OS-BS, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, und a href=http://www.gnu.org/software/grub/;GRUB/a. p 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=http://gag.sourceforge.net/;GAG/a, OSBS, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, y a href=http://www.gnu.org/software/grub/;GRUB/a. p 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 succ?s a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, et a href=http://www.gnu.org/software/grub/;GRUB/a. p 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 href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, ?s a a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./nl/faq4.html === RCS file:
Re: Clearing the console each time a user logs out
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. Nick. In gmane.os.openbsd.misc, Mark Zimmerman markz...@frii.com 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:\ :np:sp#9600:\ :cl=\E[H\E[2J: This does not work ? An idea ? The FAQ entry for this has been wrong for a few releases now. Try this: 2|std.9600|9600-baud:\ :sp#9600:\ :cl=\E[H\E[2J: Assuming /etc/ttys has this for the console: console /usr/libexec/getty std.9600 vt220 off secure
