Re: Do you need/prefer the non-DUID option in the installer?
Joel Sing, 12 Apr 2015 03:14: On Wednesday 01 April 2015, frantisek holop wrote: Theo de Raadt, 30 Mar 2015 18:09: IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' Sounds like you might use this. Want to trial a diff that adds support? If it is wrong, don't worry, someone will hate your bad diff, and do it right. (That is pretty much the history of DUID support in the tools) yes, i'd like to use it :) i have numerous softraid encrypted usb dongles that i'd like to mount/unmount using DUID's. i started looking into this when i first reported it: http://marc.info/?l=openbsd-miscm=138198909623938w=2 but it was not the one liner i hoped for :) i'll try to revisit. -f FWIW this is now fixed in r1.351 of src/sys/dev/softraid.c. lovely, thank you very much. -f -- first came reality. then there was wolfenstein 3d...
Re: Do you need/prefer the non-DUID option in the installer?
On Wednesday 01 April 2015, frantisek holop wrote: Theo de Raadt, 30 Mar 2015 18:09: IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' Sounds like you might use this. Want to trial a diff that adds support? If it is wrong, don't worry, someone will hate your bad diff, and do it right. (That is pretty much the history of DUID support in the tools) yes, i'd like to use it :) i have numerous softraid encrypted usb dongles that i'd like to mount/unmount using DUID's. i started looking into this when i first reported it: http://marc.info/?l=openbsd-miscm=138198909623938w=2 but it was not the one liner i hoped for :) i'll try to revisit. -f FWIW this is now fixed in r1.351 of src/sys/dev/softraid.c. -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: Do you need/prefer the non-DUID option in the installer?
Theo de Raadt, 30 Mar 2015 18:09: IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' Sounds like you might use this. Want to trial a diff that adds support? If it is wrong, don't worry, someone will hate your bad diff, and do it right. (That is pretty much the history of DUID support in the tools) yes, i'd like to use it :) i have numerous softraid encrypted usb dongles that i'd like to mount/unmount using DUID's. i started looking into this when i first reported it: http://marc.info/?l=openbsd-miscm=138198909623938w=2 but it was not the one liner i hoped for :) i'll try to revisit. -f -- light at end of tunnel will be out until further notice.
Re: Do you need/prefer the non-DUID option in the installer?
On Mon, Mar 30, 2015 at 4:04 PM, frantisek holop min...@obiit.org wrote: Theo de Raadt, 15 Mar 2015 12:15: Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I'm sorry, but I don't understand the usage case here which blocks DUIDS, so let's see a better explanation or demonstration. When you have DUIDs in /etc/fstab, you can still use the disk partitions using the raw disk names. The partitions are obvious. Figuring out which disk it is, is really easy, lots of options to provide the translation. And as far as I know, all the tools have been adapted to accept DUID. IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' -f -- doubt is the beginning of wisdom Completely hackish and subject to races, but fulfills my needs right now: https://github.com/acamari/getdev
Re: Do you need/prefer the non-DUID option in the installer?
Theo de Raadt, 15 Mar 2015 12:15: Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I'm sorry, but I don't understand the usage case here which blocks DUIDS, so let's see a better explanation or demonstration. When you have DUIDs in /etc/fstab, you can still use the disk partitions using the raw disk names. The partitions are obvious. Figuring out which disk it is, is really easy, lots of options to provide the translation. And as far as I know, all the tools have been adapted to accept DUID. IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' -f -- doubt is the beginning of wisdom
Re: Do you need/prefer the non-DUID option in the installer?
Theo de Raadt, 15 Mar 2015 12:15: Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I'm sorry, but I don't understand the usage case here which blocks DUIDS, so let's see a better explanation or demonstration. When you have DUIDs in /etc/fstab, you can still use the disk partitions using the raw disk names. The partitions are obvious. Figuring out which disk it is, is really easy, lots of options to provide the translation. And as far as I know, all the tools have been adapted to accept DUID. IIRC 'bioctl -d' cannot deal with DUID's. not a showstopper, just sayin' Sounds like you might use this. Want to trial a diff that adds support? If it is wrong, don't worry, someone will hate your bad diff, and do it right. (That is pretty much the history of DUID support in the tools)
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 dera...@cvs.openbsd.org 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 Sun, 15 Mar 2015 21:27:41 -0600 Abel Abraham Camarillo Ojeda
acam...@verlet.org wrote:
On Sun, Mar 15, 2015 at 5:45 PM, Theo de Raadt dera...@cvs.openbsd.org
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
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 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 :)
Do you need/prefer the non-DUID option in the installer?
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? Ken
Re: Do you need/prefer the non-DUID option in the installer?
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? Ken I think there were issues on Octeon when using DUIDs by default. Did anyone else run into this too? No description of the issue. Please...
Re: Do you need/prefer the non-DUID option in the installer?
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? Ken I think there were issues on Octeon when using DUIDs by default. Did anyone else run into this too? -- jasper
Re: Do you need/prefer the non-DUID option in the installer?
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. Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?!
Re: Do you need/prefer the non-DUID option in the installer?
15 марта 2015 г. 21:26 пользователь Robert Peichaer rob...@peichaer.org написал: On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: 15 ?? 2015 ??. 20:50 Theo de Raadt dera...@cvs.openbsd.org ??: 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question. Virtualization appliances: after cloning you could get a different drive ID, right? - and thus get a non-bootable system. That's the only real issue I know. Hope to be wrong. :) -- Vadim Zhukov At least on VMware, the DUID does not change after cloning. Nice to know, thanks. I'll recheck tomorrow (at $mainjob) how it goes with KVM. -- Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
On March 15, 2015 8:18:59 PM GMT+01:00, Vadim Zhukov persg...@gmail.com wrote: 15 марта 2015 г. 21:26 пользователь Robert Peichaer rob...@peichaer.org написал: On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: 15 ?? 2015 ??. 20:50 Theo de Raadt dera...@cvs.openbsd.org ??: 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question. Virtualization appliances: after cloning you could get a different drive ID, right? - and thus get a non-bootable system. That's the only real issue I know. Hope to be wrong. :) -- Vadim Zhukov At least on VMware, the DUID does not change after cloning. Nice to know, thanks. I'll recheck tomorrow (at $mainjob) how it goes with KVM. It surely shouldn't, as the DUID is part of the disklabel, which is none of VMware's business. /Alexander -- Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
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? I prefer not using DUIDs. --patrick
Re: Do you need/prefer the non-DUID option in the installer?
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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question.
Re: Do you need/prefer the non-DUID option in the installer?
It's very nice to make a system without DUID's in that case. Better question is: Why? The only visible effect from the admin perspective is the first column in /etc/fstab, which now contains an unambigious tag. All the sysadm tools can the DUID names.
Re: Do you need/prefer the non-DUID option in the installer?
15 марта 2015 г. 20:50 пользователь Theo de Raadt dera...@cvs.openbsd.org написал: 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question. Virtualization appliances: after cloning you could get a different drive ID, right? - and thus get a non-bootable system. That's the only real issue I know. Hope to be wrong. :) -- Vadim Zhukov
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 09:03:45PM +0300, Vadim Zhukov wrote: 15 ?? 2015 ??. 20:50 Theo de Raadt dera...@cvs.openbsd.org ??: 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question. Virtualization appliances: after cloning you could get a different drive ID, right? - and thus get a non-bootable system. That's the only real issue I know. Hope to be wrong. :) -- Vadim Zhukov At least on VMware, the DUID does not change after cloning. -- -=[rpe]=-
Re: Do you need/prefer the non-DUID option in the installer?
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. j.
Re: Do you need/prefer the non-DUID option in the installer?
Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I think you could eliminate the DUID question for laptops. it's always right there. I'd like to keep it for server's but don't know if that's reasonably possible in the installer On Sun, Mar 15, 2015 at 11:49 AM, Theo de Raadt dera...@cvs.openbsd.org 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question.
Re: Do you need/prefer the non-DUID option in the installer?
Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I'm sorry, but I don't understand the usage case here which blocks DUIDS, so let's see a better explanation or demonstration. When you have DUIDs in /etc/fstab, you can still use the disk partitions using the raw disk names. The partitions are obvious. Figuring out which disk it is, is really easy, lots of options to provide the translation. And as far as I know, all the tools have been adapted to accept DUID. I think you could eliminate the DUID question for laptops. it's always right there. I'd like to keep it for server's but don't know if that's reasonably possible in the installer The installer makes no differentiation between laptops and servers.
Re: Do you need/prefer the non-DUID option in the installer?
On 3/15/15, Michael W. Lucas mwlu...@michaelwlucas.com wrote: On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?! As someone who recently had several OpenBSD boxes in production, in a variety of roles: I can't imagine why DUIDs wouldn't work. We defaulted to DUIDs the moment they became available. They worked fine. Even for the Linux guys. If someone has a particular dislike of DUIDs, they can easily change them back. Anyone who has a whole bunch of OpenBSD boxes probably has uses a post-install script, and a couple lines of sed/awk/perl/whatever will make them happy. The ridiculousness of this point is beyond ... beyond ... well, it is silly. The installation script right now, as everyone is used to, asks a simple question. With a yes (the default) or a no answer everyone's preference and need are met. You are arguing to make more work -- which certainly means more time, more effort and less convenience, with potential introduction of errors -- for a single group of people, just so the other group isn't bothered to press the enter key to accept the default yes answer during installation? Is this the problem you are trying to solve? One less press of the enter key for you? Are you serious?! --patrick If you have one OpenBSD box, and you just don't like DUIDs, again, it's really easy to revert. ==ml PS: Yes, I still have OpenBSD hosts. But I'm no longer a pro sysadmin, so I can't claim to be running a server farm or anything like that. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: Do you need/prefer the non-DUID option in the installer?
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?
Do all arches work with DUIDs now? I have a recollection of problems somewhere not all that long ago. Might have been sparc or vax or something. DUID support is unconditional in the installer. It is possible to have some disks that have non-OpenBSD labels, in which case the DUID might not be stored. But that won't be a boot disk... I don't care whether the installer uses DUIDs or not, as long as 1) they work and 2) the option to use /dev/sd0a etc remains in fstab. Naturally.
Re: Do you need/prefer the non-DUID option in the installer?
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.
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?! As someone who recently had several OpenBSD boxes in production, in a variety of roles: I can't imagine why DUIDs wouldn't work. We defaulted to DUIDs the moment they became available. They worked fine. Even for the Linux guys. If someone has a particular dislike of DUIDs, they can easily change them back. Anyone who has a whole bunch of OpenBSD boxes probably has uses a post-install script, and a couple lines of sed/awk/perl/whatever will make them happy. If you have one OpenBSD box, and you just don't like DUIDs, again, it's really easy to revert. ==ml PS: Yes, I still have OpenBSD hosts. But I'm no longer a pro sysadmin, so I can't claim to be running a server farm or anything like that. -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Re: Do you need/prefer the non-DUID option in the installer?
On 3/15/15, Michael W. Lucas mwlu...@michaelwlucas.com wrote: On Sun, Mar 15, 2015 at 01:06:37PM -0600, Theo de Raadt wrote: Look, if people keep being unspecific on how DUIDs interfere with their usage patterns, then the non-DUID configuration mode is going to go away. WHY must be use the non-DUID option in the installer??!?!?! As someone who recently had several OpenBSD boxes in production, in a variety of roles: I can't imagine why DUIDs wouldn't work. We defaulted to DUIDs the moment they became available. They worked fine. Even for the Linux guys. If someone has a particular dislike of DUIDs, they can easily change them back. Anyone who has a whole bunch of OpenBSD boxes probably has uses a post-install script, and a couple lines of sed/awk/perl/whatever will make them happy. The ridiculousness of this point is beyond ... beyond ... well, it is silly. The installation script right now, as everyone is used to, asks a simple question. With a yes (the default) or a no answer everyone's preference and need are met. You are arguing to make more work -- which certainly means more time, more effort and less convenience, with potential introduction of errors -- for a single group of people, just so the other group isn't bothered to press the enter key to accept the default yes answer during installation? Is this the problem you are trying to solve? One less press of the enter key for you? Are you serious?! Hmm. I find this interesting. Once in a while a user goes off their rocker and thinks they are in control of the decisions the developers put into the source tree... Get back onto your meds. 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.
Re: Do you need/prefer the non-DUID option in the installer?
Do all arches work with DUIDs now? I have a recollection of problems somewhere not all that long ago. Might have been sparc or vax or something. I don't care whether the installer uses DUIDs or not, as long as 1) they work and 2) the option to use /dev/sd0a etc remains in fstab.
Re: Do you need/prefer the non-DUID option in the installer?
Here is a similar use-case: I maintain a number of HA clusters with fully automatic bi-directional synchronization using rdist. To achieve this I have as few file differences as possible and those that must differ (mostly hostname.$if) being entirely scriptable -- the sole noteable exception is /etc/myname that drives the reconciliation script. Obviously, the logs and temporary files are excluded, but every file necessary to configure and operate the system must be included. Now for the tricky part relevant to the title subject -- most of the clusters are not created by cloning, so their DUIDs are independent. Most of my clients are SMBs and do not realize to what extent they rely on the infrastructure appliances as the commercial appliances these servers replace do not generally support HA-clustering (that feature being marketed to Enterprises not SMBs). Once the client is educated and discovers that the incremental cost to add HA is relatively low, they go for it; however now that the primary server is busy under load, the additional cluster member(s) are built using installation image rather than direct cloning. 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. -Jacob. On 15 Mar 2015 at 12:12, Bob Beck wrote: Yes I do. when I install machines that I dump/restore clone, I do not use DUID's. it's very nice to make a system without DUID's in that case. I think you could eliminate the DUID question for laptops. it's always right there. I'd like to keep it for server's but don't know if that's reasonably possible in the installer On Sun, Mar 15, 2015 at 11:49 AM, Theo de Raadt dera...@cvs.openbsd.org 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? I prefer not using DUIDs. OK, I think Ken made a mistake mentioning preferences. The real question is if anyone has a use-case where DUIDs do not work. Preference has nothing to do with it. If DUIDs have no downsides, and only the upsides that they were designed to support, then it is time to remove the installation question. The non-DUID access patterns continue to work, of course. That is also not part of the question.
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: Do you need/prefer the non-DUID option in the installer?
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... In disklabel, you can see the duid for a drive; disklabel sd0 | grep duid Alternatively, sysctl knows them too sysctl hw.disknames There are circumstances where a disk can lack a duid, because they have no way to store the information. But these are rare, and not typical storage.
Re: Do you need/prefer the non-DUID option in the installer?
On 15 March 2015 at 23:38, Theo de Raadt dera...@cvs.openbsd.org wrote: 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... In disklabel, you can see the duid for a drive; disklabel sd0 | grep duid Alternatively, sysctl knows them too sysctl hw.disknames There are circumstances where a disk can lack a duid, because they have no way to store the information. But these are rare, and not typical storage. For those faced with onerous task of manually changing a duid infested fstab to the equivalent non-DUID one I present the (not quite complete, but it's off the top of my head) script. Sorry 'bout the gmail de-indentation. Needs some more sed magic to put /dev/sdNn rather than sdN.n in the fstab lines generated. I'm sure true script mages (I name no names) could make it much more elegant. Perhaps this will alleviate some of the panic engendered by suddenly facing a duid fstab. :-) I leave the changes to do the reverse process as an exercise for the reader. No fair looking at the install script source. Ken #!/bin/ksh # De-DUID an fstab. OIFS=$IFS IFS=, set -- $(sysctl -n hw.disknames) IFS=$OIFS cp /etc/fstab /tmp/fstab entries=$* for _entry in $entries; do OIFS=$IFS IFS=: set -- $_entry if [[ -n $2 ]]; then echo $1 has a DUID of $2 sed -e /$2/s//$1/p /tmp/fstab /tmp/fstab.new cp /tmp/fstab.new /tmp/fstab fi IFS=$OIFS done #cp /tmp/fstab /etc/fstab
Re: Do you need/prefer the non-DUID option in the installer?
On Sun, Mar 15, 2015 at 5:45 PM, Theo de Raadt dera...@cvs.openbsd.org 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...
