doas /usr/bin/vi best practice
Dear misc@ readers,
I was wondering what you normally do when running vi with doas if a
.exrc file is present in the normal user $HOME.
"doas /usr/bin/vi" without any special rules will end up with:
/home/just22/.exrc: not sourced: not owned by you
'cause the $HOME variable is preserved by default. The only thing that
came to my mind was to add to doas.conf(5):
permit setenv { -HOME } :wheel cmd /usr/bin/vi
but I really don't know if this is the best practice.
Any hints?
All the best
-- Alessandro DE LAURENZIS
[mailto:jus...@atlantide.t28.net]
LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: doas /usr/bin/vi best practice
What is the larger problem you are trying to solve?
Thanks,
--
Raul
On Sun, Aug 13, 2017 at 9:19 AM, Alessandro DE LAURENZIS
wrote:
> Dear misc@ readers,
>
> I was wondering what you normally do when running vi with doas if a .exrc
> file is present in the normal user $HOME.
>
> "doas /usr/bin/vi" without any special rules will end up with:
>
> /home/just22/.exrc: not sourced: not owned by you
>
> 'cause the $HOME variable is preserved by default. The only thing that came
> to my mind was to add to doas.conf(5):
>
> permit setenv { -HOME } :wheel cmd /usr/bin/vi
>
> but I really don't know if this is the best practice.
>
> Any hints?
>
> All the best
>
> -- Alessandro DE LAURENZIS
> [mailto:jus...@atlantide.t28.net]
> LinkedIn: http://it.linkedin.com/in/delaurenzis
>
Re: Hot Spare in Softraid?
On 08/12/17 15:02, Federico Giannici wrote: > On 08/12/17 20:48, noah pugsley wrote: >> On Sat, Aug 12, 2017 at 10:55 AM, Federico Giannici >> wrote: >>> Is it possible to set a "Hot Spare" chunk for a RAID1 Softraid? >>> From the "bioctl" man page seems that this functionality is available for >>> "RAID controllers" only. >>> Is it correct? >>> >>> Thanks. you can just leave a drive on-line and waiting to be added to an array. When you have a failure, you COULD have it happen on its own with appropriate monitoring and scripting, or you could wait until an optimal time to rebuild. Rebuilding is a performance impacting task, you might want some say about when it happens. >> I don't know about that, but from softraid(4) I know that: >> >> "RAID 1 >> A mirroring discipline. It copies data across more than one chunk to >> provide for data loss. Read performance is increased, though at the >> cost of write speed. Unlike traditional RAID 1, softraid supports the >> use of more than two chunks in a RAID 1 setup." >> >> So, why not a 3 disk mirror? > > Good point, but now I have two more questions: > > 1) What about the "cost of write speed"? Will writing times increase > further with another disk? Is it negligible? depends on your needs (and hw). Test, don't speculate. Yes, writes will be slower. Reads MAY be faster. But the performance loss may be trivial compared to the difficulty when you have a multiple disk failure. I've often wished hw raid controllers accepted three disk RAID1 configs. > 2) What happens when one of the three disk goes bad? Is it signaled in > any way? The softraid goes "degraded" or remains "Online" (I suppose the > latter)? Don't ask these questions of others, their answers may or may not apply to you, and YOU need to find them out yourself the easy way...before you find out the hard way. Practice RAID response and recovery. Nick.
D-Link DWA-137 A1 and DWA-140 D1 to work (patch)
Hello, misc!
I propose a patch for working Wi-Fi device D-Link DWA-130 B1 and DWA-140 D1:
http://wikidevi.com/wiki/D-Link_DWA-137
http://wikidevi.com/wiki/D-Link_DWA-140_rev_D1
In my case, both devices were identifiable and worked on OpenBSD-6.1 amd64,
if anyone else has these devices, please confirm their function with my patch.
I hope that developers will include support for these devices.
Best regards,
Mike Korbakov
patch for OpenBSD-current:
Index: dev/usb/if_run.c
===
RCS file: /cvs/src/sys/dev/usb/if_run.c,v
retrieving revision 1.122
diff -u -p -r1.122 if_run.c
--- dev/usb/if_run.c2 Aug 2017 18:26:47 - 1.122
+++ dev/usb/if_run.c13 Aug 2017 21:01:24 -
@@ -154,7 +154,9 @@ static const struct usb_devno run_devs[]
USB_ID(CYBERTAN,RT2870),
USB_ID(DLINK, DWA127),
USB_ID(DLINK, DWA130F1),
+ USB_ID(DLINK, DWA137A1),
USB_ID(DLINK, DWA140B3),
+ USB_ID(DLINK, DWA140D1),
USB_ID(DLINK, DWA160B2),
USB_ID(DLINK, DWA162),
USB_ID(DLINK, RT2870),
Index: dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.675
diff -u -p -r1.675 usbdevs
--- dev/usb/usbdevs 2 Aug 2017 18:25:45 - 1.675
+++ dev/usb/usbdevs 13 Aug 2017 21:01:24 -
@@ -1525,6 +1525,7 @@ product DLINK RTL8192CU_4 0x330b RTL8192
product DLINK DWA131B 0x330d DWA-131 rev B
product DLINK DWA125D1 0x330f DWA-125 rev D1
product DLINK DWA123D1 0x3310 DWA-123 rev D1
+product DLINK DWA137A1 0x3317 DWA-137 rev A1
product DLINK DWA131E1 0x3319 DWA-131 rev E1
product DLINK DWL122 0x3700 DWL-122
product DLINK DWLG120 0x3701 DWL-G120
@@ -1544,6 +1545,7 @@ product DLINK DWA140B30x3c15 DWA-140 r
product DLINK DWA160B2 0x3c1a DWA-160 rev B2
product DLINK DWA127 0x3c1b DWA-127
product DLINK DWA162 0x3c1f DWA-162 Wireless Adapter
+product DLINK DWA140D1 0x3c20 DWA-140 rev D1
product DLINK DWA130F1 0x3c25 DWA-130 rev F1
product DLINK DSB650C 0x4000 10Mbps Ethernet
product DLINK DSB650TX10x4001 10/100 Ethernet
Index: dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.687
diff -u -p -r1.687 usbdevs.h
--- dev/usb/usbdevs.h 2 Aug 2017 18:26:16 - 1.687
+++ dev/usb/usbdevs.h 13 Aug 2017 21:01:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.687 2017/08/02 18:26:16 stsp Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -1532,6 +1532,7 @@
#defineUSB_PRODUCT_DLINK_DWA131B 0x330d /* DWA-131 rev
B */
#defineUSB_PRODUCT_DLINK_DWA125D1 0x330f /* DWA-125 rev
D1 */
#defineUSB_PRODUCT_DLINK_DWA123D1 0x3310 /* DWA-123 rev
D1 */
+#defineUSB_PRODUCT_DLINK_DWA137A1 0x3317 /* DWA-137 rev
A1 */
#defineUSB_PRODUCT_DLINK_DWA131E1 0x3319 /* DWA-131 rev
E1 */
#defineUSB_PRODUCT_DLINK_DWL1220x3700 /* DWL-122 */
#defineUSB_PRODUCT_DLINK_DWLG120 0x3701 /* DWL-G120 */
@@ -1551,6 +1552,7 @@
#defineUSB_PRODUCT_DLINK_DWA160B2 0x3c1a /* DWA-160 rev
B2 */
#defineUSB_PRODUCT_DLINK_DWA1270x3c1b /* DWA-127 */
#defineUSB_PRODUCT_DLINK_DWA1620x3c1f /* DWA-162
Wireless Adapter */
+#defineUSB_PRODUCT_DLINK_DWA140D1 0x3c20 /* DWA-140 rev
D1 */
#defineUSB_PRODUCT_DLINK_DWA130F1 0x3c25 /* DWA-130 rev
F1 */
#defineUSB_PRODUCT_DLINK_DSB650C 0x4000 /* 10Mbps
Ethernet */
#defineUSB_PRODUCT_DLINK_DSB650TX1 0x4001 /* 10/100
Ethernet */
Index: dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.681
diff -u -p -r1.681 usbdevs_data.h
--- dev/usb/usbdevs_data.h 2 Aug 2017 18:26:16 - 1.681
+++ dev/usb/usbdevs_data.h 13 Aug 2017 21:01:26 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.681 2017/08/02 18:26:16 stsp Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -2506,6 +2506,10 @@ const struct usb_known_product usb_known
"DWA-123 rev D1",
},
{
+ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA137A1,
+ "DWA-137 rev A1",
+ },
+ {
USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA131E1,
"DWA-131 rev E1",
},
@@ -2580,6 +2584,10 @@ const struct usb_
Re: doas /usr/bin/vi best practice
If you are trying to avoid that message: > /home/just22/.exrc: not sourced: not owned by you It could be that you are in that in your home directory and vi is trying to read the local .exrc script on startup. In vi(1): > exrc, ex [off] > Read the startup files in the local directory. To turn off this feature, put "set noexrc" into your ~/.exrc The key is to understand what configuration files vi looks for when starting up. This is mentioned toward the bottom of vi(1). It seems like the precedence goes (from least to most): /etc/vi.exrc, ~/.exrc, ./.exrc. (For clarity, I am not including ~/.nexrc and ./.nexrc.) I used to have "set exrc" and would get the behavior you are describing, specifically while in my home directory. Disabling that feature with "set noexrc" removes ./.exrc from what vi scans for at startup. This is the setup I currently have. I have /etc/vi.exrc as a system-wide default vi configuration. In $HOME/.exrc I have general vi macros, and in $HOME/.nexrc I have programming language specific macros. Normally, what I will do is update ~/.exrc if I want to add some new features, and copy that to /etc/vi.exrc to have it available system-wide. Another observation I made was that because doas' default behavior is to reset the environment except for HOME, among others, executing `doas vi` gives me access to macros defined in both ~/.exrc ~/.nexrc even though I am root. If I change to root with `su` and then open `vi`, I only get access to /etc/vi.exrc and lose access to macros defined in ~/.nexrc. I have been annoyed by this problem, too, because I had to keep pressing enter to clear that error message, instead of the file instantaneously opening. I could not be bothered to investigate further until you had mentioned it.
Re: Hot Spare in Softraid?
12.08.2017 22:02, Federico Giannici пишет: On 08/12/17 20:48, noah pugsley wrote: On Sat, Aug 12, 2017 at 10:55 AM, Federico Giannici wrote: Is it possible to set a "Hot Spare" chunk for a RAID1 Softraid? From the "bioctl" man page seems that this functionality is available for "RAID controllers" only. Is it correct? Thanks. I don't know about that, but from softraid(4) I know that: "RAID 1 A mirroring discipline. It copies data across more than one chunk to provide for data loss. Read performance is increased, though at the cost of write speed. Unlike traditional RAID 1, softraid supports the use of more than two chunks in a RAID 1 setup." So, why not a 3 disk mirror? Good point, but now I have two more questions: 1) What about the "cost of write speed"? Will writing times increase further with another disk? Is it negligible? 2) What happens when one of the three disk goes bad? Is it signaled in any way? The softraid goes "degraded" or remains "Online" (I suppose the latter)? Thanks From bioctl(8): "Configure softraid0 with 4 special devices (/dev/sd2e, /dev/sd3e, /dev/sd4e, /dev/sd5e) and a RAID level of 1: # bioctl -c 1 -l /dev/sd2e,/dev/sd3e,/dev/sd4e,/dev/sd5e softraid0" -N You can use sensorsd to monitor raid status. Like this: /etc/sensorsd.conf: hw.sensors.softraid0.drive0:command=echo "Raid state: %t %2" | mail -s "Sensor %t changed" -r nore...@kasakoff.net ka...@kasakoff.net sysctl hw.sensors output: hw.sensors.softraid0.drive0=online (sd4), OK
Re: D-Link DWA-137 A1 and DWA-140 D1 to work (patch)
On Mon, Aug 14, 2017 at 01:41:22AM +0300, Mike Korbakov wrote: > Hello, misc! > > I propose a patch for working Wi-Fi device D-Link DWA-130 B1 and DWA-140 D1: > http://wikidevi.com/wiki/D-Link_DWA-137 > http://wikidevi.com/wiki/D-Link_DWA-140_rev_D1 > > In my case, both devices were identifiable and worked on OpenBSD-6.1 amd64, > if anyone else has these devices, please confirm their function with my patch. > I hope that developers will include support for these devices. > > Best regards, > Mike Korbakov Comitted, thanks!
