RAID 1C: Writing Random Data During Installation
Namaste Misc, ASSUMPTION Consider two disks sd0 and sd1 assembled into sd2 with RAID 1C as the discipline. QUESTION Which of the following is the correct way to write random data for the RAID 1C discipline during installation? 1) # dd if=/dev/urandom bs=1m 2>dd.result | tee /dev/rsd0c > /dev/rsd1c In other words, writing random data to the disk before initializing the disk (fdisk), creating the partitions (disklabel) and assembling the softraid device sd2 (bioctl). 2) # dd if=/dev/urandom of=/dev/rsd2c bs=1m In other words, writing random data to the assembled disk sd2. 3) Both of the above. CONTEXT >From the Full Disk Encryption section of Disk FAQ [1]: " ... You may want to write random data to the drive first with something like the following: # dd if=/dev/urandom of=/dev/rsd0c bs=1m This can be a very time-consuming process, depending on the speed of your CPU and disk, as well as the size of the disk. If you don't write random data to the whole device, it may be possible for an adversary to deduce how much space is actually being used. ... " >From my limited understanding, this concept of writing random data is applicable for the RAID 1C discipline as well. However, the guidance on this is missing for RAID 1C discipline. Hence the question. Dhanyavaad, Dharma Artha Kama Moksha [1] - https://www.openbsd.org/faq/faq14.html#softraidFDE
Re: Use daily(8), weekly(8), or monthly(8) but read less mail
Hallo Ibsen, > I want to use the altroot facility, but I don't want to read the mails > about the the backup succeeding and nothing else failing. > > Reading the scripts and the manual pages, I see no support for sending > the daily, weekly, or monthly mails only on failure. I also see > no support for running ROOTBACKUP outside of the daily script. > Of course I could change the scripts, but I would rather not. > Also, once I receive the mail, I don't see an easy way to classify > it as having a failure or not. > > What do you do if you want to use the altroot facility (or some > other part of the periodic system maintenance scripts) and want > to read reports only when something failed? Based on my limited understanding, the ask is for an email to be sent only when there is a failure. Failures could be in multiple places, including the very mechanism of the mail being sent. An email in the inbox represents the entire chain of maintenance having executed successfully. Lack of an email in the inbox may seem to be a successful execution, but may not always be the case. Given a multitude of machines, it is possible that reading an email a day per machine may be an onerous task. However, on the balance, it may still seem to be a better tradeoff than believing everything to be ok, when it is not. Just my two øres. > With great humility, > > Ibsen S. Ripsbusker > > Dhanyavaad, Dharma Artha Kama Moksha.
Probable error in softraid(4) documentation
Namaste misc, The softraid(4) documentation states the following in the CAVEAT section [1]: "Stacking disciplines (CRYPTO on top of RAID 1, for example) is not supported at this time." Based on my limited understanding, RAID 1C seems to allow the above. Also, Dhanyavaad Stefan for RAID 1C. Dhanyavaad Dharma Artha Kama Moksha [1] - https://man.openbsd.org/softraid.4#CAVEATS
Re: Is CRONTAB(5) random really random ?
Namaste Rachel, Theo(s), > Sent: Thursday, January 05, 2023 at 5:50 PM > From: "Theo de Raadt" > To: "Theo Buehler" > Cc: "Rachel Roch" , "Misc" > Subject: Re: Is CRONTAB(5) random really random ? > > Theo Buehler wrote: > > > On Thu, Jan 05, 2023 at 06:15:43PM +0100, Rachel Roch wrote: > > > According to the docs : > > > > > > > A random value (within the legal range) may be obtained by usingthe > > > > ‘~’ character in a field. > > > > The random numbers are drawn once and then repeated regularly. This > > behavior has always bothered me but never enough to spend the time > > needed to fix it (it's not immediately obvious how to do it). A > > workaround is to use a > > > > sleep $((RANDOM \% 512)) && run_whatever > > > > construct. The number to the right of the modulo should be a power of 2 > > to avoid modulo bias. > > Any solution would need to be careful, so that a operation doesn't run > multiple times in an hour. Each column should be '0 + random % range', > but multiple columns contain ~, it gets weird. > > The following thread may be helpful: "Regarding randomized times in crontab" https://marc.info/?l=openbsd-misc&m=158705405304672&w=2 Dhanyavaad, Dharma Artha Kama Moksha
Re: Probable error in softraid(4) documentation
Namaste Stuart, Tobias, > Sent: Thursday, January 05, 2023 at 4:58 PM > From: "Tobias Fiebig" > To: misc@openbsd.org > Subject: Re: Probable error in softraid(4) documentation > > Heho, > > On Wed, 2023-01-04 at 00:04 +, Stuart Henderson wrote: > > stacking would refer to creating one softraid (say a raid1 mirror) > > and then creating a separate softraid device (say a crypto volume) > > using the first softraid disk as a component. > > Incidentally, if you happen to have a thing for doing _really_ stupid > things, you _can_ actually do that; I ran RAID10 that way for some > time... but then again I would not recommend anybody else doing it for > data they are in some form even mildly attached to... ;-) > > I think the important part here is the meaning of 'supported'; In the > context of the man page i read it as: > > 'By holding it a certain way, you _could_ make stacking "work". > However, it will not integrate well into the system, you will have to > jump through interesting hoops, there is not even a remote suggestion > of standard operations working (say, replacing a disk), and you are > more likely than not to encounter unexpected behavior which will > ultimately migrate the data stored on your disks to an unstructured and > unusable pile of mangled bits; Furthermore, in case that _does_ happen, > please do not annoy people with your stacking attempt; We told you not > to do it, we told you it would hurt, and you did it anyway.' > > So... i'd say there is no error in softraid(4), even if you can > technically make stacking "work". > > With best regards, > Tobias > > Dhanyavaad for helping me understand that RAID 1C is a single discipline. I had incorrectly understood what stacking meant. I apologize for my mistake. Dhanyavaad, Dharma Artha Kama Moksha
Probable bug in disklabel(8) -R
Namaste misc,
Introduction:
While using the "-R" option with disklabel(8), in a specific case, the
target disk may not match the source disk label parameters.
More precisely, the target disk's boundend may not match with the source
disk.
Overview:
A disk with storage greater than 2 TB and 512 bytes/sector.
Exclusively for use with OpenBSD.
Disk fdisk'ed with MBR and then disklabel'ed to extend the boundaries
beyond the 2 TB, as helpfully described by Crystal Kolipe [1].
Disk label stored.
Disk label (emulated/simulated) corruption.
Disk label restored with disklabel -R, using the original disk label.
Problem:
The restored disk will have the boundend at 2 TB, instead of the source
disk's full disk size boundend.
Detailed steps to reproduce:
On a non-essential ok-if-trashed disk with greater than 2 TB storage and
512 bytes/sector, which is attached as /dev/sdX:
-> Wipe out the previous content (not sure if this is the best way to do
this)
# dd if=/dev/zero of=/dev/sdX bs=1M count=10
-> Create device
# cd /dev
# sh MAKEDEV sdX
-> Create MBR
# fdisk -iy sdX
-> Adjust the boundaries to fill the whole disk.
# disklabel -E sdX
Label editor (enter '?' for help at any prompt)
sdX> b
Starting sector: [64]
Size ('*' for entire disk): [4294961621] *
sdX*> w
sdX> q
No label changes.
-> Store the disk label
# disklabel sdX > layout
-> Wipe out the previous content (not sure if this is the best way to do
this)
# dd if=/dev/zero of=/dev/sdX bs=1M count=10
-> Create MBR
# fdisk -iy sdX
-> Restore the disk label
# disklabel -R sdX layout
-> Store the disk label
# disklabel sdX > layoutrestored
On inspection, the boundend parameter for layout and layoutrestored are
different.
The net effect may be that the restored disk has not had its boundary
extended beyond the fdisk limit of 2 TB.
Acknowledgement:
Koti Koti Dhanyavaad to Crystal for her mail pointing out that MBR can
be used for disks greater than 2 TB, when used exclusively with OpenBSD.
>From a cursory internet search, it seems that this information was part
of the FAQ earlier [2].
However, I did not know this, and I was very pleasantly surprised.
Since GPT takes up one partition, and there are only 16 to work with, I
am now going from GPT to MBR, to use that extra partition.
And also because I do not understand GPT. Not that I understand MBR
much, but anyways. May be next Janm.
Dhanyavaad,
Artha Dharma Kama Moksha
[1] - https://marc.info/?l=openbsd-misc&m=167060793529661
[2] - https://daemonforums.org/showthread.php?t=10116#post60708
Re: Probable bug in disklabel(8) -R
Namaste Crystal, Koti Koti Dhanyavaad for your reply. > Sent: Friday, February 03, 2023 at 3:21 PM > From: "Crystal Kolipe" > To: "Puru Shartha" > Cc: "Misc" > Subject: Re: Probable bug in disklabel(8) -R > > On Fri, Feb 03, 2023 at 04:02:43PM +0100, Puru Shartha wrote: > > Problem: > > The restored disk will have the boundend at 2 TB, instead of the source > > disk's full disk size boundend. > > ... > > > The net effect may be that the restored disk has not had its boundary > > extended beyond the fdisk limit of 2 TB. > > This is not a bug. > > The current behaviour is intentional, and was added in revision 1.169 of > disklabel.c. If this is intentional, would one have to first extend the boundaries and then restore the disk label? > But thanks for reporting it anyway. Please no thanks, I am a nobody. Dhanyavaad, Dharma Artha Kama Moksha
