amd (BSD automounter) stuck at nfsv2?
Dear misc@ readers, I actually use amd for a long time, but I never realized this until I started to share large files... First things first, my amd configuration is neither fancy nor complex: just22@poseidon:[~] cat /etc/rc.conf.local [...] # BSM automounter portmap_flags=# DARPA port to RPC program number mapper amd_flags=-a /tmp/amd_mnt -l syslog -x all [...] just22@poseidon:[~] cat /etc/amd/master /home/nfs nfs.map just22@poseidon:[~] cat /etc/amd/nfs.map /defaults type:=nfs;rhost:=argo.atlantide.net;opts:=rw,soft,intr bt rfs:=/home/export/bt just22 rfs:=/home/export/just22 The NFS server (argo) runs OpenBSD 5.7 and exports some directories through NFSv3. The problem on the client side seems that amd is using NFSv2 and UDP instead of NFSv3 and TCP: just22@poseidon:[~] mount | grep nfs amd:3892 on /home/nfs type nfs (v2, udp, intr, timeo=100, retrans=101) argo:/home/export/bt on /tmp/amd_mnt/argo/home/export/bt type nfs (v2, udp, soft, intr, timeo=100) I also tried something like: just22@poseidon:[~] cat /etc/amd/nfs.map /defaults type:=nfs;rhost:=argo.atlantide.net;opts:=rw,soft,intr,nfsv3 bt rfs:=/home/export/bt just22 rfs:=/home/export/just22 and also: just22@poseidon:[~] cat /etc/amd/nfs.map /defaults type:=nfs;rhost:=argo.atlantide.net;opts:=rw,soft,intr,vers=3,proto=tcp bt rfs:=/home/export/bt just22 rfs:=/home/export/just22 but nothing changes. Of course, NFSv2 works properly only for files smaller than 2GB, so this is becoming a showstopper for this setup. Info on the net are very sparse: I found [1] and [2], but the proposed solutions didn't work for me (in particular, I didn't succeed with type:=host - if this is the right way, please give me some further details on the correct setup to use); reading the amd's documentation didn't help either (the manual repeatedly says that the automounter should defaults to NFSv3, so I'm a bit lost...) What's wrong with my configuration? Any hints? Thanks in advance for your help. All the best [1] http://serverfault.com/questions/335061/openbsd-configuration-client-unable-to-mount-via-nfs-using-berkeley-automounter [2] http://www.openbsdsupport.org/sharedhomes.html -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
OpenBSD support for Lenovo Y50-70
Hello misc@, I am looking to purchase a Lenovo Y50-70 laptop, and I'm wondering whether anyone else has this laptop and whether it works with OpenBSD. Here is a link to a page with a list of models and hardware: http://shop.lenovo.com/gb/en/laptops/lenovo/y-series/y50/ A search of misc@ and tech@ doesn't come up with anything, so I'd appreciate any information anyone has. Some specific questions: * Does anyone know what Lenovo BGN Wireless actually means and whether OpenBSD supports it? * According to this email (http://marc.info/?l=openbsd-miscm=143317399504723w=2), the Intel Dual Band Wireless-AC 3160 network card listed on one of the models of Y50-70 works fine, does anyone else know anything about it? * I realise that the Nvidia GPU will not work with OpenBSD, but is it possible to turn off the Nvidia GPU in the BIOS (or UEFI) and just use the Intel integrated graphics that comes with the i7-4720HQ CPU? There is KMS support for the Intel graphics, correct? Thanks in advance for any help. -- Kaashif Hymabaccus GPG: 3E810B04
Re: rc.subr: $pexp does not always contain daemon flags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Jun 16, 2015 at 01:32:11PM +, nusenu wrote: Rebooting (without changing the config) solves the issue but is not really an option. I cannot reproduce here. I can reproduce it every (first) time on multiple fresh OpenBSD 5.7 machines. I'm using ansible to automate the entire setup. I assume timing plays a role here (that is probably why automation matters). If you want to try to reproduce it (on a test machine) with ansible. You can find the ansible role here: Thanks. I will have a look then. But do note that I am using current -- so that may explain why I did not see this issue. Problem solved. My ansible role reloaded the service before setting the flags. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhY7/AAoJEFv7XvVCELh05gkQAJXcLrxnsVtLxTeyuv4MCNPL 8pUZ+L4I02aPtCruozvSTVTV1+8kV8+U+wd479KuZVh2G6gTufosQT9twNduRdIY BVxhCe9vD842FZ9AVNLs1ACdWmrAW3zwdoDqm6AXBinEoCo92JjElNefYGxJdHFg gi9HSJPz+q2OYjetHejCDmdqGi4MXQ2Un/J7hm0+Gey8/1UeWYKQ6I6Opob0bwzj DUX0J+aRKQ93nnRkY1LPI/KPi9E+XrtratGkaDAsxEKO57nzgPkRv97ROyHD5DN/ wk/EZNdsCKuYFcKsdN5BprXP5AWlmC+Ci9G4fs7/4irAY1BbVLxrzeQn+Hdy6JG8 hjNqz4/Xg/pIGuoOoMpf4IU52XlRjt5B9VWdFcwL+1URftk2Z7eXfTHmBs/KLGtN q/BWte6a0J1Bxsp0OpM5E66KI8MvoQyk2zZiFAPPfpqtiN5bAc907xzyFX9hwWd5 4RytEp8aLGsXNk5rVuMXcTrL/II9sYdkGXaZyVtrNd/i/vDzt2vDwkk8/F/w2eTs QjT3aUR/s/Fz20BYeOHKhLi5T+dP69iMYvI0y1aEKMST5nYUZs/ZkjhSrCr3RheD zV3hR8MPsmyt6f5/hvSYlnkS5yH4ntorFuIu2YSb9Hwfe7SFLY8X962pioD25grQ cSNqs88bMaaTOmsignyt =nLZJ -END PGP SIGNATURE-
Re: when SSDs are not so solid or why no TRIM support can be a good thing :)
Chris Cappuccio, 19 Jun 2015 09:59: The problem identified in this article is _NOT_ TRIM support. It's QUEUED TRIM support. It's an exotic firmware feature that is BROKEN. Suffice to say, if Windows doesn't exercise an exotic feature in PC hardware, it may not be well tested by anybody! the author has clarified in the comments bellow the article that TRIM was the issue and not QUEUED TRIM. -f -- you have 2 choices for dinner -- take it or leave it.
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 imagine you have N services named: service service1 service2 ... Now you want to stop 'service' and you run: 'rcctl stop service' all (not just one) of them are gone? rc.subr invokes pkill and does a startswith match but does not require a perfect/complete match. What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhWugAAoJEFv7XvVCELh0U6wP/0vOT73glYbmFllM2WlLLCqF 7PAovqHtwI+fqYeD7rovfHutOXkLvw4AYGEAeCpsP+og3WNY27Qh3BtVpWY/eNI2 N7FlBSmMBmD/QJPArYkQdmj8C5NTgkHwjUoFfOaGsf/hHIIiqunT4ohkYi9+XbPG LW8i/aqL2MCpMhQJn6isMsVpdjLp0Vf7A1n0BuR03cwwzO/Ij4xkZFubmdj8KOSv FZy5SjNDPteTTOFPxrvR47Nuz6ztPAo1BWmHdr9E2acLyvervN5dcKuSHNMitZrH fMwSgo6hkcu/Uj36fybguMPasvfCwS6Q5rD7D0M6MjuQDFfBw6mOckbcr//65iK1 n4/UDU9VyT041Rhjq0uXVIVNmbpHbKCSUFg1yBRpRwJSE7Lx7QDRF152y/v0Ble9 qa28bkOfhSbGwbDwasg7sP7CsZrqI7ebyQNVq8jxDrR5B0wM4Wkpt7VcGTRRgvhj clAl0hhUNxlCI+TGRslaWs1O839m+gDS6Lf3eaoEMSrWdKrBitUsISzZykPyoSu0 pNVQQtWFkII+CyP4E8Vh5HM8WQp01odEueOV8Vf8DUVMV14WTd9nAbILx2KEgNU5 aRvXolxtGQfTW94UN59e9LJWRm0l7ikRoS7XKJ/ZQQd0IV91AySVrl6OFHybrk09 gmimAMIHiQkuhFpu4TYW =MTr3 -END PGP SIGNATURE-
Re: how to restore partion order , openbsd's grub
On Sat, Jun 20, 2015 at 12:06:44PM +0900 or thereabouts, Tuyosi Takesima wrote: title ARCH root (hd0,1) - canNOT boot kernel /boot/vmlinuz-linux root=/dev/sdb2 ro initrd /boot/initramfs-linux.img Surely (hd0,1) should be /dev/sda2. No? Not sure if it makes any difference but Arch no longer supports grub-0.97 except through AUR. https://wiki.archlinux.org/index.php/GRUB_Legacy Regards Moss
Re: how to restore partion order , openbsd's grub
On Sat, Jun 20, 2015 at 02:26:18PM +0100 or thereabouts, Maurice McCarthy wrote: On Sat, Jun 20, 2015 at 12:06:44PM +0900 or thereabouts, Tuyosi Takesima wrote: title ARCH root (hd0,1) - canNOT boot kernel /boot/vmlinuz-linux root=/dev/sdb2 ro initrd /boot/initramfs-linux.img Surely (hd0,1) should be /dev/sda2. No? Apologies the root (h0,1) determines the root for grub. Do you have 3 separate installations of grub?
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? So this cannot be used as a generic solution. Wouldn't it make sense to use '-x' by defaut in rc.subr to be more strict and less likely to unintentionally kill other daemons in general? If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhcKOAAoJEFv7XvVCELh0qVoP/jdy1m0vE9/k8qVQfmlPlpMz QiXwM0y7SoGThrDnALeCuPflVGvenTtitNj7RtaSDsJRTyFKRW+VOQYJO/mP/3u/ DdKjvuEe6MtrcJYBgZLrcQw3EeWZM0NBsfO3wscC3hoWkN6dDeoNGh2w2GlUqm0J 414QZT5YwAuL2QwSHOZjPa3ks83JK1egs+g33YdSml3/ur8NAHqUX9V2aAWDaNcv HPZoQEf5JIRcfET28RxGYFIswybSQW5suZ2hcXrImZcypuTXqGv+e4pXs9YI4Jc2 jaae+HGc5UDIZmu8yBEmhdSm4OG+em6CwiG4MTyFrPte9a+AoAjp8gC9LiiFqbWl cNv5vugMJZHsXlaBwE4Be/w69L8/+r/gSnepEnSjJhUzygDCyv0MzrwkEdvHnxzu 7YZv1opDFkuOjWMNhPKA73lIDW0qmlti2Xl3q4BHb2XlvPhvOtWn2t1JhoHDl+nd r24UdruJLfOv+oXHr2nObIr1KlBvZ1DaPxm3ybRsJvdFLzHmBdWGGGVerA8Jlcv4 izZuKjTqQMfA/J4ESdqoLbcHzY/DGm/sbB8Grmez0rCtAzuinKCauQ5zX9IPV8p4 IskuzIwxHoXSPNN74+ycN+3XSlc/at/y5KxJBT2Nuf5ZR1H/V4Vp0IkedkM5qhmL l4j33IkmBZAG7e7T1UWT =9Asr -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
On Sat, Jun 20, 2015 at 10:02:18PM +0200, nusenu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? No. Would you mind elaborating on that? Actually, you need to elaborate how one is supposed to include every possible options into pexp. -- Antoine
Re: how to restore partion order , openbsd's grub
*Hi Maurice http://marc.info/?a=10990797805r=1w=2* sorry ,PC has 1 ATA HDD(sd0 =sda) and 1 USB HDD(sd1 =sdb). i rsync arch from sdb to sda by linux , and edit it's /etc/fstab . then arch boot by openbsd's grub . i have two boot loader . ATA HDD's one is made by puppy's grub4dos and USB HDD'sone is made by openbsd's grub. now in openbsd cat /grub/menu.lst - default 0 timeout 10 title OpenBSD root (hd0,0) chainloader +1 title Porteus-v3.1 32bit root (hd1,0) kernel/boot/syslinux/vmlinuz changes=/porteus load=003-lxqt;locales-ja initrd/boot/syslinux/initrd.xz title p571-HDD root (hd1,0) kernel /p571/vmlinuz initrd /p571/initrd.gz title ARCH ok in ATA HDD - now can boot root (hd1,0) kernel /boot/vmlinuz-linux root=/dev/sda1 ro initrd /boot/initramfs-linux.img but ATA HDD has only 70GB. so iwant to use USB HDD(500GB). # disklabel sd0 #size offset fstype [fsize bsize cpg] a: 59945120 96356352 4.2BSD 2048 163841 c:1563014880 unused i: 9216 4196352 ext2fs -arch j: 4194304 2048 unknown # disklabel sd1 a: 62914560 2048 4.2BSD 2048 163841 # / c:9767731680 unused i:524288000 62916608 ext2fs -arch j: 8388608587206656 unknown k:251658240595597312 ext2fs -data area l:129515568847257600 ext2fs -ext2 - regards
understanding rc.subr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Some daemons will happend more stuffs to the command line
than just
$daemon $daemon_flags
Then $pexp should include everything that a daemon can
append via rc.conf.local settings?
No.
Would you mind elaborating on that?
Actually, you need to elaborate how one is supposed to include
every possible options into pexp.
Ok, I'll try. My understanding was:
In cases - where the rc script is basically containing only
daemon=...
. /etc/rc.d/rc.subr
rc_cmd $i
a daemon is started by taking
1)
daemon=
from the rc script
and 2)
daemon_flags defined in rc.conf.local (if any).
from rc.subr:
rc_start() {
${rcexec} ${daemon} ${daemon_flags} ${_bg}
[...]
so there is nothing else included in such cases that would cause a
problem with pkill using '-fx'.
pexp incorporates these two parts:
pexp=${daemon}${daemon_flags:+ ${daemon_flags}}
In such default cases using
pkill with '-fx' would work out of the box and pkill would kill only
if daemons and parameters match completely, correct so far?
Using '-fx' would be problematic if the rc script itself defines
rc_start() that is different from the one in rc.subr.
Writing this email made it more clear :)
So they override rc_start() but still expect that rc.subr's
restart/stop works with them out of the box.
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJVhdTnAAoJEFv7XvVCELh0EO8P/005u61VFjmCWs7BMq9uUDE2
H43/bsQPB0rC71GBP4pFru5B2387miQ64vkhubXO/xZ7AaDF+SW519cfybAT/oIQ
1CUd4sgn2VuliDiSTXEa9YA0XQOoWe9wBOpYN/WgMtlGy3d+g69wx+HVJrbdYtPw
fXFfRDgAiZ91GFk2oEJaQj3KoF3ZxKNCRmHfNYB8ZvdTLdP4LMR7QQAdBnZmLkR/
TvzrpNdjipSVW0Kq/zXHT7fOX0TiEg6KtpR2/zFpfKLqk8KjAUdgn/yJGDDQ5YTo
hmm9pGAfWq2nD2E2d9SkOgP2kL5KnX9p3Nod03IhbB40ILpVhvNEBlFdaEeu92Lt
7V3My3Wc1iz4cCAYkvlzKeJi4ayNZaW/T0MRXGqpB2ZCl3CNXHBBNURSKiHYgZQr
e1nuFE9+tVtiAgb8nicMLMPpEWQF6Oyv01+I17IfOGVdwn5xSLUwPVhDGxAEPJam
t2q3+9erZCrFA3o50xxZrG5JdmLU7j1F7k7m+bB+o+iKqR/HdbeqRFdAMfjD+oVg
2QAFWjHMQyObzbNW2BpvluP6y9QLZKXilP9rJuvdJMBFOpJZyrstqNExwtHKKBmL
i6BX9N9HwJ5qsG65SUBBVWxP8b4uayXhQ362ewnjowjFliQrfeiQELrZLNdXBlZO
Fc7XaazScxdYKMxXSbo2
=cUxX
-END PGP SIGNATURE-
Extend RAID 5
Hi! I'm planning to replace my OpenBSD media center, and was going to test the new [1] RAID 5 features and functions, but I'm really unexperienced in this field. How does this work; can I create a 4 disks RAID5 array (w/ bioctl(8)) and then later just add another disk, and fdisk+growfs? Can I create a RAID5(4 disks) and a RAID0(2 disks) array and then create another RAID0 from these two former softraids? Thanks, Daniel [1] - http://marc.info/?l=openbsd-techm=142877132517229w=2 -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: bug in rc.subr: kills more than it should (patch)
On Sat, Jun 20, 2015 at 03:33:20PM +0200, nusenu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 imagine you have N services named: service service1 service2 ... Now you want to stop 'service' and you run: 'rcctl stop service' all (not just one) of them are gone? rc.subr invokes pkill and does a startswith match but does not require a perfect/complete match. What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags So this cannot be used as a generic solution. If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. iQIcBAEBCgAGBQJVhWugAAoJEFv7XvVCELh0U6wP/0vOT73glYbmFllM2WlLLCqF 7PAovqHtwI+fqYeD7rovfHutOXkLvw4AYGEAeCpsP+og3WNY27Qh3BtVpWY/eNI2 N7FlBSmMBmD/QJPArYkQdmj8C5NTgkHwjUoFfOaGsf/hHIIiqunT4ohkYi9+XbPG LW8i/aqL2MCpMhQJn6isMsVpdjLp0Vf7A1n0BuR03cwwzO/Ij4xkZFubmdj8KOSv FZy5SjNDPteTTOFPxrvR47Nuz6ztPAo1BWmHdr9E2acLyvervN5dcKuSHNMitZrH fMwSgo6hkcu/Uj36fybguMPasvfCwS6Q5rD7D0M6MjuQDFfBw6mOckbcr//65iK1 n4/UDU9VyT041Rhjq0uXVIVNmbpHbKCSUFg1yBRpRwJSE7Lx7QDRF152y/v0Ble9 qa28bkOfhSbGwbDwasg7sP7CsZrqI7ebyQNVq8jxDrR5B0wM4Wkpt7VcGTRRgvhj clAl0hhUNxlCI+TGRslaWs1O839m+gDS6Lf3eaoEMSrWdKrBitUsISzZykPyoSu0 pNVQQtWFkII+CyP4E8Vh5HM8WQp01odEueOV8Vf8DUVMV14WTd9nAbILx2KEgNU5 aRvXolxtGQfTW94UN59e9LJWRm0l7ikRoS7XKJ/ZQQd0IV91AySVrl6OFHybrk09 gmimAMIHiQkuhFpu4TYW =MTr3 -END PGP SIGNATURE- -- Antoine
Re: bug in rc.subr: kills more than it should (patch)
On Sat, Jun 20, 2015 at 09:44:14PM +0200, nusenu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 What do you think about this patch to require a perfect match when sending invoking pkill/pgrep? Won't work. Carefully read pgrep(1) again. After reading the man page again I even found something more fitting: -x Require an exact match of the process name, or argument list if -f is given. The default is to match any substring. Since it seems to do what I'm aiming for, could you give me an example for what won't work? thanks! my tests: # ps ax|grep tor 24508 ?? S 0:03.85 tor -f torrc2 19493 ?? S 0:00.79 tor -f torrc # pgrep -fx tor # no result expected # pgrep -fx 'tor -f torrc' # expected result: 19493 but NOT 24508 19493 # pgrep -fx 'tor -f torrc2' # expected result: 24508 24508 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? No. So this cannot be used as a generic solution. Wouldn't it make sense to use '-x' by defaut in rc.subr to be more strict and less likely to unintentionally kill other daemons in general? No, for the reason I mentioned. If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? No, you need to edit the rc script for that. -- Antoine
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Some daemons will happend more stuffs to the command line than just $daemon $daemon_flags Then $pexp should include everything that a daemon can append via rc.conf.local settings? No. Would you mind elaborating on that? So this cannot be used as a generic solution. Wouldn't it make sense to use '-x' by defaut in rc.subr to be more strict and less likely to unintentionally kill other daemons in general? No, for the reason I mentioned. If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? No, you need to edit the rc script for that. That is unfortunate since I aimed to use the rc file that comes with the package (or links pointing to it). -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhcbKAAoJEFv7XvVCELh0m4EQALXdPkbPwv6wbflfZUaOVWso gPB/HdWUvbu75bn2i+tqY/Ik8tIGYpRXcXRLMfFPRRAQashXZ0cAfEHaTP5eeD6r xmFOPuKVuvq1TI4Aw5CVViwb2Eif73jAJ8lxT+l8weR7nrbayZlk8658wHsZOsE5 2Dytch0lmwtmxdqY/Min6APa/7iuQN1X5DMssiMDbsDSD6gbSZRJikmuw05klRtr HGX6SJ42sgBMi/lTvDx9FN9BfldtPboYbKaSNpyG2cI9HbUA46qeIN63zp/G0zRV pQCpF4qCJlYO1oZmMFKl2p7jDHjB8wo0FBMz75aCep4aZPT0KJeSSopgvCGU21Fw 35Jjpf86qW/XUtsfFGkLR9PnqrHA+HZmGK8jCcC1Y6rHsZx8LBDjZl624TWOhDZz uDA1TuNG8IFStc9MvDDG8Z4NFUmXKufkhY+Voy6GLdMQ7rt4S5g3tFzry9O6LBQA lXTIZDasaDfa0MEQ49Jlm56XXw7NTcYY9N6v5siRLMY1mdTPhqe+b4vT1Y8Orj7Q YVM5GvnldUsR0I8PrzgZpQLRC8WdyaEJni0C21T3spP0maXLj2ESgSEaOMCnz1Rd FbxXD2uxOhF/ya2KecAGtnQxz40J+NL+wPIH+/uA2kfm3AEqKJ68Bxrsht+p/RqH UXzDnwH/dhAxKOSYjB9H =c4F0 -END PGP SIGNATURE-
Re: bug in rc.subr: kills more than it should (patch)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If you want to match the exact complete command line, adapt pexp accordingly and end it with '$'. Can $pexp be set via /etc/rc.conf.local? No, you need to edit the rc script for that. After thinking about creating a custom rc script to explicitly set $pexp I realized that it won't solve my problem since that safes other daemons from my rc script unintentionally killing them but not the other way around. The other rc script (that comes with a package) will still kill my daemons, no matter how I define pexp in my rc script. Is there a best practice - way to work around this? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVhdwmAAoJEFv7XvVCELh09skQAJuwKnc5xPRf3PBdtmcDBIrV kY/tusrnfosWjXrT4XmbGJSIzSp49u16OZInZr7BZ/aw/fWuhJEJaYLRerF3IkGn zrjn6UBs0NpD1K6PnMlX7UuDu3zsUjnNpiVmIpbo3ZhVS9VE52lyrUYbgeDn9Gkd +fI5v13/eNoZjdvtiAncikWOZVnG/EwTg/OnB5vtiVXJj5Gjq7XcinO3ymvkSHlF 6EhVyRM7ASUhpYqtF5tRvn5kMsdyrv8CfVaeteGudyhXJLs8+hVKCrRD1BhiHUqV D2FwDtxH46rw3xggP+DCSn+qtxNyxCYxTqMowzNwJVnRz7UbxorWoT4MowPylZO7 D+r7XtoVIy0AQj7ekyJUaSRSyt2k/A6T48zIYc5IZg2j5p0zkk4m2+Bi/5TkZcoB cicGpkP96l/2Tj19L70SDkag5HX247xg5d3kcp6kWpeA4LnCWj9KH19Z/mHeTG5A HPG5yzWz/WtEaSZ/3m12VPAIjpePEQ1Z8wKvQYgFQhbhJ4ualaaRXivAZsrwaWN4 vG0PnSChbKc+Prf2I61b9nU/oVLKazEutqCSvwTwSzIZYXHQ6tB0iJdhCfkVOVau 2h/S+7GEgRfTMtFCWb6FRpegOpksrRYRNAnDhDGXJvNRrOUQCVm648m5mmOZigCg 2yu3feYu83pRfY+qXQ7P =hGUH -END PGP SIGNATURE-
FFS snapshoting/softupdates status
Hello, just going thorough papers/presentations and surprisingly found that kind of snapshoting is already supported in UFS since '99, FreeBSD probably supports that, while NetBSD seems to not and even removed softupdates from 6.0 release[1]. I've also found remark from Henning Brauer in his OpenBSD sucks presentation that snapshoting is not supported[2] and that running fsck on background with softupdates is not supported since it has never been finished for OpenBSD[3]. On the other hand I've found [4] which is positive about possible inclusion of functionality in OpenBSD but just manpower is missing. The question here is if this 11 years old email still apply or the way to OpenBSD is already planned in a more secure/elegant way? If so, then what exactly if I may ask? Thanks! Karel [1]: https://en.wikipedia.org/wiki/Unix_File_System [2]: http://quigon.bsws.de/papers/2015/asiabsdcon/mgp8.html [3]: http://quigon.bsws.de/papers/2015/asiabsdcon/mgp9.html [2]: http://marc.info/?l=openbsd-miscm=107954189429732w=4
Re: Extend RAID 5
On 06/20/15 14:48, LÉVAI Dániel wrote: Hi! I'm planning to replace my OpenBSD media center, and was going to test the new [1] RAID 5 features and functions, but I'm really unexperienced in this field. How does this work; can I create a 4 disks RAID5 array (w/ bioctl(8)) and then later just add another disk, and fdisk+growfs? [1] - http://marc.info/?l=openbsd-techm=142877132517229w=2 I think you did some creative reading of that posting. Rebuild means (in this context) replacing a failed disk, not reorganizing the array over more disks. Adding new disks to an existing RAID5 another task (if anyone is even considering it). Can I create a RAID5(4 disks) and a RAID0(2 disks) array and then create another RAID0 from these two former softraids? you mean, making a RAID0 from combination of two other softraids? Yes and no -- you can do it, but they don't auto-assemble. I've done this with softraid mirrored disks providing an encrypted softraid disk. The mirror auto-assembles at boot, but the encrypted layer has to be manually activated after boot. So, if you have some data that you want encrypted, this can work -- but the os will probably have to be on non-encrypted space, and you will activate the encrypted space post-boot. Maybe that's useful to you, maybe not. In general, I don't like systems that don't boot to a fully-functional state on their own. Nick.
