pf on bridge interface not working
This came through to me from the list with “no content”, so I’m trying again.
——
My box has three interfaces, dc0 to manage, em0 and em1 for bridging external
LAN to internal LAN.
hostname.em0: up
hostname.em1: up
hostname.bridge0: add em0 add em1 up
Bridge works, traffic flows across no problem.
Add filtering.
pf.conf:
filtered = "{ em1 }”
not_filtered = "{ lo, dc0, em0, bridge0 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on em1 all
`tcpdump -nettti pflog0` shows lots of filtered packets. Traffic is blocked.
-But-
make one simple change to filter on the bridge0 interface—
pf.conf:
filtered = "{ bridge0 }”
not_filtered = "{ lo, dc0, em0, em1 }”
block log on $filtered
set skip on $not_filtered
`doas pfctl -sr`
block drop log on bridge0 all
traffic is NOT blocked and everything flows right on through. (!?)
`tcpdump -nettti pflog0` shows no packets being filtered.
Am I overlooking something?
E
Re: pf on bridge interface not working
pf on bridge interface not working
Re: File this bug, or not?
So you would expect a kernel panic when a live drive gets pulled from a RAID5? Sent from my iPhone > On Jan 20, 2021, at 7:12 AM, Stuart Henderson wrote: > > On 2021-01-19, Jordan Geoghegan wrote: >> >>> On 1/18/21 2:47 PM, Eric Zylstra wrote: >>> I’ve set up a 6 drive RAID-5. Just for the experience of degrading >>> and rebuilding the RAID, I popped a drive out. Within a few seconds the >>> machine kerneled and dropped into ddb. Is there any chance this would be >>> expected considering the machine’s SATA is not hot-swappable? >>> >>> I’m looking into setting up a serial connection so I can capture the >>> debut output (I already have photos of the traces for all 8 CPU, but >>> would like to give serial output instead). I would not file a report if >>> this behavior falls into “not great, but expected”. > > Assume this is softraid rather than one of the supported hardware > RAID options which usually work ok with hotswap most of the time. > >> Just thought I'd chip in here too FWIW: >> >> I've never successfully hot swapped a drive with OpenBSD before. >> I have hardware that does it fine on Linux, but fails on OpenBSD. I >> haven't caused the kernel to panic when pulling a drive, but the OS >> fails to detect any newly attached SATA or SAS drives. It's certainly >> caused some frustration when trying to rebuild a RAID array on a >> production machine. Maybe I just have wonky hardware, but I've tried >> this on a number of releases, on several different pieces of hardware, >> on several different arches. I have no solution to offer, just thought >> I'd share my experience with hot swapping drives on OpenBSD. > > Even if you do have a proper hotswappable drive chassis or external > SCSI or whatever, there's no way to rescan drives on OpenBSD. > >
File this bug, or not?
Misc, I’ve set up a 6 drive RAID-5. Just for the experience of degrading and rebuilding the RAID, I popped a drive out. Within a few seconds the machine kerneled and dropped into ddb. Is there any chance this would be expected considering the machine’s SATA is not hot-swappable? I’m looking into setting up a serial connection so I can capture the debut output (I already have photos of the traces for all 8 CPU, but would like to give serial output instead). I would not file a report if this behavior falls into “not great, but expected”. Thanks, EZ
Re: openbsd.org down?
ezylstra ~ % traceroute openbsd.org traceroute to openbsd.org (129.128.5.194), 64 hops max, 52 byte packets 1 dslrouter (192.168.0.1) 0.811 ms 0.405 ms 0.295 ms 2 stpl-dsl-gw13.stpl.qwest.net (207.109.2.13) 10.595 ms 10.860 ms 10.977 ms 3 stpl-agw1.inet.qwest.net (207.109.3.97) 57.309 ms 14.162 ms 10.966 ms 4 4.68.38.177 (4.68.38.177) 11.740 ms 11.695 ms 15.970 ms 5 ae-0-25.bar3.minneapolis2.level3.net (4.69.218.182) 14.949 ms 12.693 ms 11.964 ms 6 v135.core1.msp1.he.net (184.105.52.221) 13.082 ms 11.910 ms 11.796 ms 7 100ge10-1.core1.ywg1.he.net (184.105.64.86) 19.679 ms 19.895 ms 20.369 ms 8 100ge5-2.core1.yxe1.he.net (184.104.192.70) 28.868 ms 28.466 ms 28.587 ms 9 100ge11-2.core1.yeg1.he.net (72.52.92.61) 53.860 ms 53.360 ms 53.231 ms 10 university-of-alberta-sms.10gigabitethernet2-2.core1.yeg1.he.net (184.105.18.50) 54.089 ms 54.084 ms 54.264 ms 11 katzcore-esqgw.corenet.ualberta.ca (129.128.255.41) 54.326 ms cabcore-esqgw.corenet.ualberta.ca (129.128.255.35) 54.093 ms 53.920 ms 12 * * * 13 * * * 14 * * * 15 obsd3.srv.ualberta.ca (129.128.5.194) 53.712 ms 54.430 ms 53.976 ms Problems on campus at Alberta? EZ > On Apr 13, 2020, at 8:22 AM, Mario Theodoridis wrote: > > For me with /etc/mail/spamd.conf > > nixspam:\ >:black:\ >:msg="Your address %A is in the nixspam list\n\ >See http://www.heise.de/ix/nixspam/dnsbl_en/ for details":\ >:method=http:\ >:file=www.openbsd.org/spamd/nixspam.gz > > sleep $((RANDOM % 2048)) && /usr/libexec/spamd-setup > > produces > > ftp: connect: Operation timed out > > since yesterday morning 4am CEST. > > But running > > wget http://www.openbsd.org/spamd/nixspam.gz > --2020-04-13 14:59:07-- http://www.openbsd.org/spamd/nixspam.gz > Resolving www.openbsd.org (www.openbsd.org)... 129.128.5.194 > Connecting to www.openbsd.org (www.openbsd.org)|129.128.5.194|:80... > connected. > HTTP request sent, awaiting response... 200 OK > Length: 18025 (18K) [text/plain] > Saving to: 'nixspam.gz' > > nixspam.gz > 100%[=>] > 17.60K 37.7KB/sin 0.5s > > 2020-04-13 14:59:08 (37.7 KB/s) - 'nixspam.gz' saved [18025/18025] > > just now works. > > Mit freundlichen Grüßen/Best regards > > Mario Theodoridis > > On 13.04.2020 14:02, infoomatic wrote: >> not reachable for days now in Austria, Germany, Czech Republic >> On 13.04.20 11:01, SP2L Tom wrote: >>> Greetings. >>> >>> >>> It was and it is still up&running. >>> At least, I can reach OpenBSD site. >>> >>> >>> Best regards. >>> Tom >>> >>> W 13 kwietnia 2020 10:23:18 Sebastien Marie napisał: >>> On Mon, Apr 13, 2020 at 10:14:00AM +0300, Ilya Mitrukov wrote: > Hi, > flushing the caches doesn't help and it's still unavailable. > > Does anybody know where to report the issue? > (I'd look at openbsd.org but ... ) I suppose there is one or two openbsd developers which follow this list. So they might already know. Thanks. -- Sebastien Marie >>> >>> >>> >
Re: Kibana/Elasticsearch fail
You rock! I’ll let you know it works for me when I get a chance.
EZ
Sent from my iPhone
> On Feb 10, 2020, at 11:19 PM, Aaron Bieber wrote:
>
> On Thu, 06 Feb 2020 at 23:31:01 -0600, Eric Zylstra wrote:
>> I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using
>> pkg_add. Installs went fine. I checked out the pkg documentation
>> (pkg_reames) and followed the steps for those that had documentation to
>> follow.
>>
>> When I boot, Logstash and Kibana fail. I can use rcctl to start Logstash
>> with no problem. When I try to start Kibana, the following is what I see:
>>
>> # rcctl -d start kibana
>> doing _rc_parse_conf
>> doing _rc_quirks
>> kibana_flags empty, using default ><
>> doing _rc_parse_conf /var/run/rc.d/kibana
>> doing _rc_quirks
>> doing rc_check
>> kibana
>> doing rc_start
>> doing _rc_wait start
>> doing rc_check
>> No home directory /nonexistent!
>> Logging in with home = "/".
>> Kibana does not support the current Node.js version v10.16.3. Please use
>> Node.js v>=10.15.0 <10.16.
>> doing _rc_rm_runfile
>> (failed)
>>
>>
>> I’m not sure what to do with this. Why is Logstash not starting on reboot?
>> Why does Kibana fail? I assume there is some config that need be done,
>> because that Node.js error wouldn’t have made it to distribution, right?
>
>> that Node.js error wouldn’t have made it to distribution
>
> It did, and it's entirely my fault.
>
> Kibana is failing because it is very strict about the version of node it wants
> to use (hence the "Kibana does not support.." message).
>
> Apparently the tests I had run to verify this update worked failed:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/kibana/patches/patch-package_json?rev=1.4&content-type=text/x-cvsweb-markup
>
> Here is a diff that fixes it for 6.6 (you will have to build it from ports
> until (if?) a proper fix is in place).
>
> https://deftly.net/patches/kibana-6.6.1.diff
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/kibana/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile28 Sep 2019 09:37:54 -1.32
> +++ Makefile11 Feb 2020 04:13:52 -
> @@ -3,7 +3,7 @@
> COMMENT=browser based analytics/search interface to ElasticSearch
>
> V =6.6.1
> -REVISION =1
> +REVISION =2
> PKGNAME =kibana-${V}
> DISTNAME =kibana-oss-${V}-darwin-x86_64
>
> Index: patches/patch-package_json
> ===
> RCS file: /cvs/ports/www/kibana/patches/patch-package_json,v
> retrieving revision 1.4
> diff -u -p -r1.4 patch-package_json
> --- patches/patch-package_json13 May 2019 22:08:11 -1.4
> +++ patches/patch-package_json11 Feb 2020 04:13:52 -
> @@ -8,7 +8,7 @@ Index: package.json
>},
>"engines": {
> -"node": "10.15.1"
> -+"node": ">=10.15.0 <10.16"
> ++"node": "10.16.3"
>}
> -}
> \ No newline at end of file
>
>>
>> Thanks,
>>
>> EZ
>
> --
> PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
Kibana/Elasticsearch fail
I’ve installed the ELK packages (Elasticsearch, Logstash, Kibana) using pkg_add. Installs went fine. I checked out the pkg documentation (pkg_reames) and followed the steps for those that had documentation to follow. When I boot, Logstash and Kibana fail. I can use rcctl to start Logstash with no problem. When I try to start Kibana, the following is what I see: # rcctl -d start kibana doing _rc_parse_conf doing _rc_quirks kibana_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/kibana doing _rc_quirks doing rc_check kibana doing rc_start doing _rc_wait start doing rc_check No home directory /nonexistent! Logging in with home = "/". Kibana does not support the current Node.js version v10.16.3. Please use Node.js v>=10.15.0 <10.16. doing _rc_rm_runfile (failed) I’m not sure what to do with this. Why is Logstash not starting on reboot? Why does Kibana fail? I assume there is some config that need be done, because that Node.js error wouldn’t have made it to distribution, right? Thanks, EZ
Re: Suricata from packages
> On Jan 21, 2020, at 1:45 PM, Stuart Henderson wrote: > > On 2020-01-18, Eric Zylstra wrote: >> >> >>> On Jan 18, 2020, at 6:42 AM, Antoine Jacoutot wrote: >>> >>> On Fri, Jan 17, 2020 at 11:24:22PM -0600, Eric Zylstra wrote: >>>> OpenBSD 6.6 Generic.MP amd64 >>>> Stable. >>>> >>>> I installed suricata using pkg_add. Having trouble with starting it. > > pkg_add pointed you at the pkg-readme file when you installed suricata. > Did you follow the instructions in that file? > > The file /usr/local/share/doc/suricata/README is an empty file.
Re: Suricata from packages
The pkg-readme was perfect. Concise and all I need to know. Two minutes and
I’m good to go.
Thanks all!
EZ
Sent from my iPhone
> On Jan 21, 2020, at 3:59 PM, Stuart Henderson wrote:
>
> On 2020/01/21 15:40, Eric Zylstra wrote:
>>
>>
>>>> On Jan 21, 2020, at 1:45 PM, Stuart Henderson wrote:
>>>
>>> On 2020-01-18, Eric Zylstra wrote:
>>>>
>>>>
>>>>> On Jan 18, 2020, at 6:42 AM, Antoine Jacoutot
>>>>> wrote:
>>>>>
>>>>> On Fri, Jan 17, 2020 at 11:24:22PM -0600, Eric Zylstra wrote:
>>>>>> OpenBSD 6.6 Generic.MP amd64
>>>>>> Stable.
>>>>>>
>>>>>> I installed suricata using pkg_add. Having trouble with starting it.
>>>
>>> pkg_add pointed you at the pkg-readme file when you installed suricata.
>>> Did you follow the instructions in that file?
>>>
>>>
>>
>> The file /usr/local/share/doc/suricata/README is an empty file.
>
> Hmm, yes all the files in /usr/local/share/doc/suricata seem completely
> useless in the current version.
>
> $ grep -R . /usr/local/share/doc/suricata
> /usr/local/share/doc/suricata/NEWS:https://suricata-ids.org/news/
> /usr/local/share/doc/suricata/TODO:Plenty, and you're welcome to help!
> /usr/local/share/doc/suricata/TODO:https://suricata-ids.org/participate/
> /usr/local/share/doc/suricata/AUTHORS:Team:
> /usr/local/share/doc/suricata/AUTHORS:https://suricata-ids.org/about/team/
> /usr/local/share/doc/suricata/AUTHORS:All contributors:
> /usr/local/share/doc/suricata/AUTHORS:https://www.ohloh.net/p/suricata-engine/contributors/summary
>
> CC'ing port maintainers, can I just remove them? (Diff below).
>
> I am pretty certain that the OpenBSD-specific pkg-readme (which you let me
> know
> you found after writing this mail) has enough to fix the problem you're
> running into.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/suricata/Makefile,v
> retrieving revision 1.27
> diff -u -p -r1.27 Makefile
> --- Makefile16 Dec 2019 15:33:27 -1.27
> +++ Makefile21 Jan 2020 21:55:02 -
> @@ -4,6 +4,7 @@ COMMENT =high performance network IDS,
>
> SURICATA_V =5.0.1
> SUPDATE_V =1.1.1
> +REVISION =0
>
> DISTNAME =suricata-${SURICATA_V}
> CATEGORIES =security
> @@ -72,8 +73,6 @@ post-install:
>${INSTALL_DATA} ${WRKSRC}/*.config ${PREFIX}/share/examples/suricata
>${INSTALL_DATA} ${WRKSRC}/suricata.yaml ${PREFIX}/share/examples/suricata
>${INSTALL_DATA} ${WRKSRC}/rules/*.rules
> ${PREFIX}/share/examples/suricata/rules
> -rm ${PREFIX}/share/doc/suricata/{*.txt,GITGUIDE,INSTALL*}
> -${INSTALL_DATA} ${WRKSRC}/doc/{AUTHORS,NEWS,README,TODO} \
> -${PREFIX}/share/doc/suricata
> +rm -r ${PREFIX}/share/doc/suricata # nothing particularly useful in
> there as of 5.0.1
>
> .include
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/security/suricata/pkg/PLIST,v
> retrieving revision 1.11
> diff -u -p -r1.11 PLIST
> --- pkg/PLIST16 Dec 2019 15:33:27 -1.11
> +++ pkg/PLIST21 Jan 2020 21:55:02 -
> @@ -150,11 +150,6 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
> lib/python${MODPY_VERSION}/site-packages/suricatasc/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
> @man man/man1/suricata.1
> share/doc/pkg-readmes/${PKGSTEM}
> -share/doc/suricata/
> -share/doc/suricata/AUTHORS
> -share/doc/suricata/NEWS
> -share/doc/suricata/README
> -share/doc/suricata/TODO
> @sample ${SYSCONFDIR}/suricata/
> @sample ${SYSCONFDIR}/suricata/rules/
> share/examples/suricata/
>
>
>
>
Re: Suricata from packages
> On Jan 18, 2020, at 9:08 AM, Eric Zylstra wrote: > > > >> On Jan 18, 2020, at 6:42 AM, Antoine Jacoutot > <mailto:ajacou...@bsdfrog.org>> wrote: >> >> On Fri, Jan 17, 2020 at 11:24:22PM -0600, Eric Zylstra wrote: >>> OpenBSD 6.6 Generic.MP amd64 >>> Stable. >>> >>> I installed suricata using pkg_add. Having trouble with starting it. >>> >>> $ doas rcctl start suricata >>> …fails. No informative fail message, though. >> I get the same result with a clean OBSD 6.6 install. >> Run rcctl in debug mode. > > Notable that man rcctl(8) does not contain the word “debug”. I had to do a > web search to confirm the -d argument was what I needed to get debug output. > > > $ doas rcctl -d start suricata > doas (dixon@dixon.local <mailto:dixon@dixon.local>.) password: > doing _rc_parse_conf > doing _rc_quirks > suricata_flags empty, using default >< > doing _rc_parse_conf /var/run/rc.d/suricata > doing _rc_quirks > doing rc_check > suricata > doing rc_start > doing _rc_wait start > doing rc_check > Suricata 4.1.5 > USAGE: /usr/local/bin/suricata [OPTIONS] [BPF FILTER] > > -c : path to configuration file > -T : test configuration file (use > with -c) > -i: run in pcap live mode > -F : bpf filter file > -r : run in pcap file/offline mode > -d : run in inline ipfw divert mode > -s : path to signature file loaded in > addition to suricata.yaml settings (optional) > -S : path to signature file loaded > exclusively (optional) > -l : default log directory > -D : run as daemon > -k [all|none]: force checksum check (all) or > disabled it (none) > -V : display Suricata version > -v[v]: increase default Suricata > verbosity > --list-app-layer-protos : list supported app layer > protocols > --list-keywords[=all|csv|]: list keywords implemented by the > engine > --list-runmodes : list supported runmodes > --runmode: specific runmode modification > the engine should run. The argument > supplied should be the id for > the runmode obtained by running > --list-runmodes > --engine-analysis: print reports on analysis of > different sections in the engine and exit. > Please have a look at the conf > parameter engine-analysis on what reports > can be printed > --pidfile : write pid to this file > --init-errors-fatal : enable fatal failure on > signature init error > --disable-detection : disable detection engine > --dump-config: show the running configuration > --build-info : display build information > --pcap[=] : run in pcap mode, no value > select interfaces from suricata.yaml > --pcap-file-continuous : when running in pcap mode with a > directory, continue checking directory for pcaps until interrupted > --pcap-file-delete : when running in replay mode (-r > with directory or file), will delete pcap files that have been processed when > done > --pcap-buffer-size : size of the pcap buffer value > from 0 - 2147483647 > --simulate-ips : force engine into IPS mode. > Useful for QA > --erf-in : process an ERF file > --unix-socket[=] : use unix socket to control > suricata work > --set name=value : set a configuration value > > > To run the engine with default configuration on interface eth0 with signature > file "signatures.rules", run the command as: > > /usr/local/bin/suricata -c suricata.yaml -s signatures.rules -i eth0 > > doing _rc_rm_runfile > (failed) > The complaint appears to be that the invocation of suricata in the rc file isn’t proper. If I use the exact command on the command line, it works. This feels like a problem with the package. Am I the only one tr
Re: Suricata from packages
> On Jan 18, 2020, at 6:42 AM, Antoine Jacoutot wrote: > > On Fri, Jan 17, 2020 at 11:24:22PM -0600, Eric Zylstra wrote: >> OpenBSD 6.6 Generic.MP amd64 >> Stable. >> >> I installed suricata using pkg_add. Having trouble with starting it. >> >> $ doas rcctl start suricata >> …fails. No informative fail message, though. > > Run rcctl in debug mode. Notable that man rcctl(8) does not contain the word “debug”. I had to do a web search to confirm the -d argument was what I needed to get debug output. $ doas rcctl -d start suricata doas (dixon@dixon.local.) password: doing _rc_parse_conf doing _rc_quirks suricata_flags empty, using default >< doing _rc_parse_conf /var/run/rc.d/suricata doing _rc_quirks doing rc_check suricata doing rc_start doing _rc_wait start doing rc_check Suricata 4.1.5 USAGE: /usr/local/bin/suricata [OPTIONS] [BPF FILTER] -c : path to configuration file -T : test configuration file (use with -c) -i: run in pcap live mode -F : bpf filter file -r : run in pcap file/offline mode -d : run in inline ipfw divert mode -s : path to signature file loaded in addition to suricata.yaml settings (optional) -S : path to signature file loaded exclusively (optional) -l : default log directory -D : run as daemon -k [all|none]: force checksum check (all) or disabled it (none) -V : display Suricata version -v[v]: increase default Suricata verbosity --list-app-layer-protos : list supported app layer protocols --list-keywords[=all|csv|]: list keywords implemented by the engine --list-runmodes : list supported runmodes --runmode: specific runmode modification the engine should run. The argument supplied should be the id for the runmode obtained by running --list-runmodes --engine-analysis: print reports on analysis of different sections in the engine and exit. Please have a look at the conf parameter engine-analysis on what reports can be printed --pidfile : write pid to this file --init-errors-fatal : enable fatal failure on signature init error --disable-detection : disable detection engine --dump-config: show the running configuration --build-info : display build information --pcap[=] : run in pcap mode, no value select interfaces from suricata.yaml --pcap-file-continuous : when running in pcap mode with a directory, continue checking directory for pcaps until interrupted --pcap-file-delete : when running in replay mode (-r with directory or file), will delete pcap files that have been processed when done --pcap-buffer-size : size of the pcap buffer value from 0 - 2147483647 --simulate-ips : force engine into IPS mode. Useful for QA --erf-in : process an ERF file --unix-socket[=] : use unix socket to control suricata work --set name=value : set a configuration value To run the engine with default configuration on interface eth0 with signature file "signatures.rules", run the command as: /usr/local/bin/suricata -c suricata.yaml -s signatures.rules -i eth0 doing _rc_rm_runfile (failed) > > >> >> I’ve tried finding info in logs. Nothing informative in suricata logs nor >> /var/log/messages. >> >> $ doas /usr/local/bin/suricata -D >> …succeeds. It runs fine. That is the same command in the >> /etc/rc.d/suricata. >> >> Pointers? Suggestions? Specific details? >> >> Thanks, >> >> Eric Z >> > > -- > Antoine
Suricata from packages
OpenBSD 6.6 Generic.MP amd64 Stable. I installed suricata using pkg_add. Having trouble with starting it. $ doas rcctl start suricata …fails. No informative fail message, though. I’ve tried finding info in logs. Nothing informative in suricata logs nor /var/log/messages. $ doas /usr/local/bin/suricata -D …succeeds. It runs fine. That is the same command in the /etc/rc.d/suricata. Pointers? Suggestions? Specific details? Thanks, Eric Z
Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System
Proposing such a huge project without the ability to do it? I may have been a little disrespectful, but not the first one in the thread. And my point wasn’t to be disrespectful, but to point out that most proposals unaccompanied by code and that don’t solve obvious problems don’t seem to be received very well. Apologies if that wasn’t within bounds. E Sent from my iPhone > On Dec 31, 2019, at 3:46 PM, Theo de Raadt wrote: > > Isn't it a bit disrespectful to assume someone on misc@ is going to > write such a large diff? > >> Maybe the OP could just go ahead and replace all the Perl code with Lua and >> then ask for feedback from the other devs? That is the OpenBSD way, right? >> If it really is a great idea, they’d all be really excited. In any case, it >> would kill this thread. >> >> EZ >> >> >> Sent from my iPhone >> On Dec 31, 2019, at 1:22 PM, Daniel Corbe wrote: >>> >>> I like where this thread is headed. >>> >>> To expand on this idea, maybe we should demonstrate how diversity and >>> inclusiveness can work in an operating system via language choices. >>> Why stop at TCL and LUA? Or even scripting languages in general. Why >>> not Go, Rust, Haskell and Scala too? >>> >>> Hear me out. We can set up a raffle system so that each winner can >>> write their winning tool in their language of choice. All the >>> parallel development will even solve the "multi year effort" problem >>> that was brought up by the original poster too. Nobody will mind >>> having another 8 or 9 languages in the base system, right? >>> >>
Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System
Maybe the OP could just go ahead and replace all the Perl code with Lua and then ask for feedback from the other devs? That is the OpenBSD way, right? If it really is a great idea, they’d all be really excited. In any case, it would kill this thread. EZ Sent from my iPhone > On Dec 31, 2019, at 1:22 PM, Daniel Corbe wrote: > > I like where this thread is headed. > > To expand on this idea, maybe we should demonstrate how diversity and > inclusiveness can work in an operating system via language choices. > Why stop at TCL and LUA? Or even scripting languages in general. Why > not Go, Rust, Haskell and Scala too? > > Hear me out. We can set up a raffle system so that each winner can > write their winning tool in their language of choice. All the > parallel development will even solve the "multi year effort" problem > that was brought up by the original poster too. Nobody will mind > having another 8 or 9 languages in the base system, right? >
Re: Installboot uses wrong device for secondary boot loader
I rebooted and checked each step again. One big difference is this time on reboot, my installer USB drive was not sd0 as in my last install attempt. My RAID1 devices now were sd0 and sd1. After running through all the RAID prep steps, the install went without incident. Thanks for your help, EZ > On Apr 29, 2018, at 8:58 AM, Eric Zylstra <mailto:ezyls...@mac.com>> wrote: > > Interesting. I’ll look into that. Not sure why installboot, upon seeing an > error condition (missing MBR), would not generate an error but instead try > another device. > > EZ > > >> On Apr 29, 2018, at 8:54 AM, Joel Sing > <mailto:j...@sing.id.au>> wrote: >> >> On Saturday 28 April 2018 22:21:08 Eric Zylstra wrote: >>> I’m installing 6.3 on a RAID1. Install was fine until ending with an error >>> message, “invalid boot record signature…”. >>> I manually ran installboot: >>>> . installboot -v -r /mnt sd4 >>> >>> Hand transcription: >>> >>> Using /mnt as root >>> Installing bootstrap on /dev/rsd4c >>> Using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot >>> sd4: softraid volume with 2 disk(s) >>> sd4: installing boot loader on softraid volume >>> /mnt/usr/mdec/boot is 6 blocks x 16384 bytes >>> sd0a: installing boot blocks on /dev/rsd0c, part offset 144 >>> Master boot record (MBR) at sector 0 >>> Install boot: invalid boot record signature (0x) @ sector 0 >>> >>> I did not typo the secondary boot block install. It attempts to install on >>> sd0 instead of sd4 as specified in my command. >> >> In order to boot a softraid volume, the underlying disks have to be bootable >> with the first stage boot block being installed in the MBR (at least for >> i386/amd64). This is why it's looked at sd4, then gone to install the first >> stage boot block on sd0... however there is no MBR on this device to install >> it into. This suggests that you've not run fdisk correctly - but with >> insufficient details I can only guess. >
Re: Installboot uses wrong device for secondary boot loader
I’m following the documentation in OpenBSD FAQ: disk setup. I’m inclined to think there is a code issue since I specified device sd4 and installboot used that device for the first stage and then seems to have defaulted to sd0 for the second stage bootloader. EZ Sent from my iPhone > On Apr 29, 2018, at 4:01 AM, Stuart Henderson wrote: > >> On 2018-04-29, Eric Zylstra wrote: >> I’m installing 6.3 on a RAID1. Install was fine until ending with an error >> message, “invalid boot record signature…”. >> >> I manually ran installboot: >>> . installboot -v -r /mnt sd4 >> >> Hand transcription: >> >> Using /mnt as root >> Installing bootstrap on /dev/rsd4c >> Using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot >> sd4: softraid volume with 2 disk(s) >> sd4: installing boot loader on softraid volume >> /mnt/usr/mdec/boot is 6 blocks x 16384 bytes >> sd0a: installing boot blocks on /dev/rsd0c, part offset 144 >> Master boot record (MBR) at sector 0 >> Install boot: invalid boot record signature (0x) @ sector 0 >> >> I did not typo the secondary boot block install. It attempts to install on >> sd0 instead of sd4 as specified in my command. > > With softraid the bootblock is installed on all component disks of a raid1. > > Since the installer doesn't directly support softraid...what did you type > earlier to prepare this? >
Installboot uses wrong device for secondary boot loader
I’m installing 6.3 on a RAID1. Install was fine until ending with an error message, “invalid boot record signature…”. I manually ran installboot: >. installboot -v -r /mnt sd4 Hand transcription: Using /mnt as root Installing bootstrap on /dev/rsd4c Using first-stage /mnt/usr/mdec/biosboot, second-stage /mnt/usr/mdec/boot sd4: softraid volume with 2 disk(s) sd4: installing boot loader on softraid volume /mnt/usr/mdec/boot is 6 blocks x 16384 bytes sd0a: installing boot blocks on /dev/rsd0c, part offset 144 Master boot record (MBR) at sector 0 Install boot: invalid boot record signature (0x) @ sector 0 I did not typo the secondary boot block install. It attempts to install on sd0 instead of sd4 as specified in my command. Eric
Re: OT: Hardware keyloggers embedded in new keyboards?
On Jun 20, 2005, at 9:11 AM, Marco Peereboom wrote: nazis Invalid invocation! It must be a genuine, spontaneous reference. Now you damn us to dozens more messages in this thread because we all are now aware of the risk. EZ ;-)
