minor dd(1) posix-compliance
POSIX says the truncated things are "record(s)" not "block(s)":
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html
That's what it's historically been too:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/dd.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/bin/dd/dd.c
It sounds odd since bs= implies block sizes, not record sizes, so
perhaps there's a reason to not want to change it? Idk...
If it is to be changed, perhaps it makes sense to change the last
remaining "blocks" for odd length swabs (a few lines above this one)
too for consistency.
Index: misc.c
===
RCS file: /cvs/src/bin/dd/misc.c,v
retrieving revision 1.18
diff -u -p -r1.18 misc.c
--- misc.c 12 Feb 2014 01:18:36 - 1.18
+++ misc.c 17 Mar 2015 02:04:46 -
@@ -83,8 +83,8 @@ summary(void)
}
if (st.trunc) {
(void)snprintf(buf[2], sizeof(buf[2]),
- "%zu truncated %s\n",
-st.trunc, (st.trunc == 1) ? "block" : "blocks");
+ "%zu truncated %s\n",
+st.trunc, (st.trunc == 1) ? "record" : "records");
iov[i].iov_base = buf[2];
iov[i++].iov_len = strlen(buf[2]);
}
LibreSSL 2.1.5 released
We have released LibreSSL 2.1.5, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This release is relatively small, focused on bug fixes before 2.2.x development begins along-side OpenBSD 5.8. This or earlier LibreSSL releases may also address issues that are to be revealed by The OpenSSL Project Team on the 19th of March, 2015. The LibreSSL team is not typically apprised of OpenSSL-related security issues in advance. We will address any previously-unknown issues that are found to affect LibreSSL in future releases. Issues addressed since 2.1.4: * Fix incorrect comparison function in openssl(1) certhash command. Thanks to Christian Neukirchen / Void Linux. * Windows port improvements and bug fixes. - Removed a dependency on libgcc in 32-bit dynamic libraries. - Correct a hang in openssl(1) reading from stdin on an connection. - Initialize winsock in openssl(1) earlier, allow 'openssl ocsp' and any other network-related commands to function properly. * Reject all server DH keys smaller than 1024 bits. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Re: Do you need/prefer the non-DUID option in the installer?
Editing the device names after the fact is fine for my usage. On Sun, Mar 15, 2015 at 5:46 PM, Theo de Raadt wrote: >> I guess as long as /etc/fstab continues to support non-DUID device >> names, it can be manually edited after the initial system build. > > Of course the non-DUID device names will continue working. > > OK, this seems like a conversation with people who never read > the code to see how DUID works. What a waste of words.
Re: Do you need/prefer the non-DUID option in the installer?
On 2015/03/16 08:14, Stuart Henderson wrote: > On 2015/03/15 21:50, Stuart Henderson wrote: > > On 2015/03/15 17:37, System Administrator wrote: > > > I guess as long as /etc/fstab continues to support non-DUID device > > > names, it can be manually edited after the initial system build. > > > However, that also opens the window to transcription errors which can > > > easily render the system non-operational, requiring recovery from > > > external media, thus substantially complicating the deployment step. > > > > It can be automatically edited, too, avoiding transcription errors. > > Since I was asked off-list about this: Ha. And it seems I should have read tech before replying to mail in my inbox :)
Re: Do you need/prefer the non-DUID option in the installer?
On 2015/03/15 21:50, Stuart Henderson wrote:
> On 2015/03/15 17:37, System Administrator wrote:
> > I guess as long as /etc/fstab continues to support non-DUID device
> > names, it can be manually edited after the initial system build.
> > However, that also opens the window to transcription errors which can
> > easily render the system non-operational, requiring recovery from
> > external media, thus substantially complicating the deployment step.
>
> It can be automatically edited, too, avoiding transcription errors.
Since I was asked off-list about this:
It doesn't need anything fancy, here's a shell script to read /etc/fstab
and output a converted format on stdout. Validate it with your own files
before relying on it in case I missed anything that it needs to skip.
#!/bin/ksh -e
while read p q; do
if [[ -z $p ]] || echo $p | grep -E '(/|:|#|^swap$)' > /dev/null; then
echo "$p $q"
else
r=$(disklabel $p | sed -nE 's,^# /dev/r(.*)c:$,/dev/\1,p')
echo $r${p#*.} $q
fi
done < /etc/fstab
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, 15 Mar 2015 21:27:41 -0600 Abel Abraham Camarillo Ojeda
wrote:
> On Sun, Mar 15, 2015 at 5:45 PM, Theo de Raadt
> wrote:
>
> > DUID support was written so that we could solve a problem, without
> > a question. This is a mop-up operation. The question being posed
> > is not "shall we leave the non-DUID question", but "what DUID support
> > gaps still remain, so that we can finish those".
> >
>
>
> The only thing I'd like to have is a command or easy way
> to convert a duid to a /dev/sd0a name to use current - or future -
> utilities that don't support DUID like badblocks from e2fsprogs
> in ports...
>
> I know it can be done via the C api (opendev(3)?), and using a program
> to get the name first is subject to some races...
>
> $ badblocks `duid2dev 9d45a80cb6151768.c`
>
> but obviously this has nothing to do with the options
> in the installer...
>
i would like something like that too.. so here it is:
first 'lsdisks', a wrapper around hw.disknames to make it human readable:
lsdisks:
#!/bin/ksh
_order="\1 \2"
[ "$1" = -r ] && _order="\2 \1"
sysctl hw.disknames \
| sed -e 's/.*=//' -e 's/:,/:,/g' \
| tr ',:' '\n ' \
| sed -e 's/^.\{3\} / &/' -e "s/^\(.[^ ]*\) \(.*\)/$_order/"
$ lsdisks
wd0 41b2508dfc016300
wd1 af0d83d46bb9d50b
cd0
fd0
sd0 77080671f0866cf5
sd1 0b00356d4a1fb02d
vnd0 580308d2b000b7f1
vnd1 76d1d4260a10fbb7
$ lsdisks -r
41b2508dfc016300 wd0
af0d83d46bb9d50b wd1
cd0
fd0
77080671f0866cf5 sd0
0b00356d4a1fb02d sd1
580308d2b000b7f1 vnd0
76d1d4260a10fbb7 vnd1
and now 'duid2dev', which will print out any device starting with a given
partial duid:
duid2dev:
#!/bin/ksh
_duid=$1
if [ ${#_duid} -eq 0 ];then
echo "ERR no duid given" >&2
return 1
fi
if ! echo "$_duid" | grep -q '^[0-9a-f]*$';then
echo "ERR invalid duid '$_duid'" >&2
return 1
fi
if ! sysctl hw.disknames | grep -q ":$_duid";then
echo "ERR duid '$_duid' not found" >&2
return 1
fi
lsdisks -r | grep ^$1 | sed 's/.* //'
$ duid2dev af0
wd1
$ duid2dev 76d1d4260a
vnd1
$ duid2dev 7
sd0
vnd1
and i also wrote up an 'fstab2dev' which converts all duids to devices.
fstab2dev:
#!/bin/ksh
_fstab=/etc/fstab
[ ${#1} -gt 0 ] && _fstab=$1
cat $_fstab | while read _line;do
if [[ "$_line" != /* ]];then
_duid=${_line%%.*}
_line=${_line#*.}
echo -n "/dev/$(duid2dev $_duid)"
fi
echo "$_line"
done
$ cat /etc/fstab
0b00356d4a1fb02d.a / ffs rw 1 1
0b00356d4a1fb02d.b none swap sw 0 0
77080671f0866cf5.a /mnt ffs rw 1 1
$ fstab2dev
/dev/sd1a / ffs rw 1 1
/dev/sd1b none swap sw 0 0
/dev/sd0a /mnt ffs rw 1 1
i also found an older script i wrote 'fstab_add' that takes a device and mount
point and converts it into a duid fstab entry:
#!/bin/ksh
USAGE="$0 fsdev mntpath [fstab]"
[[ "$1" = -h ]] && { echo "USAGE $USAGE"; return 0; }
isemptyv() { eval [ \${#$1} -eq 0 ]; }
_fsdev=$1
_mnt=$2
_fstab=$3
if isemptyv _fsdev;then
echo "ERR no fs device given" >&2
return 1
fi
if [[ "$_fsdev" != [ws]d[0-9][a-p] ]];then
echo "ERR bad fs device '$_fsdev'" >&2
return 1
fi
if isemptyv _mnt;then
echo "ERR no mnt point given" >&2
return 1
fi
isemptyv _fstab && _fstab=/etc/fstab
_disk=${_fsdev%?}
_part=${_fsdev#???}
_duid=$(disklabel $_disk 2>/dev/null | sed -n 's/^duid: //p')
if isemptyv _duid;then
echo "ERR could not get duid for disk '$_disk'" >&2
return 1
fi
if [[ $_duid = ]];then
echo "ERR null duid" >&2
return 1
fi
if ! echo "$_duid" | grep '^[0-9a-f]\{16\}$';then
echo "ERR invalid duid '$_duid'" >&2
return 1
fi
echo "$_duid.$_part $_mnt ffs rw 1 1" >>$_fstab
# fstab_add wd1a /mnt2 fstab.test
# cat fstab.test
af0d83d46bb9d50b.a /mnt2 ffs rw 1 1
