Re: How to disable httpd's default
On Thu, Jan 13, 2022 at 11:46:18PM +, i...@protonmail.com wrote: > I would like to avoid httpd giving anything if a user types in the IP > address of the server. > > At first I just made an empty page, which is fine for port 80, but if > the user then types https://xxx.xxx.xxx.xxx, then the certificate for a > domain shows, which doesn't fit the IP address. Why not create a dummy self-signed certificate that only has the IP address and no domain names?
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
On Fri, Jan 14, 2022 at 01:17:47AM +0100, Leo Unglaub wrote: > >RCPT TO: RENEGOTIATING > >139809772520832:error:1420410A:SSL routines:SSL_renegotiate:wrong ssl > >version:../ssl/ssl_lib.c:2142: > > Are the last two lines expected behavour? I get then on IPv4 and IPv6. > Someone else beeing so kind trying to debug this send me something similar. Reading the manual page for openssl, specifically the section on s_client would be a very good idea.
Re: has the definition of 'nice' changed?
On Thu, Jan 13, 2022 at 06:17:54PM -0800, Jonathan Thornburg wrote: > I've just noticed something odd about the scheduling of processes with > varying 'nice' values (7.0-stable/amd64, GENERIC.MP): it appears that > processes with 'nice 20' are given more favorable scheduling than those > with 'nice 10', which is exactly the opposite of what I'd expect based > on the man page for setpriority(2), "lower priorities cause more favorable > scheduling" (and longstanding Unix experience). > > In more detail: > Right now I have 5 CPU-bound processes running (all the same binary, but > with different command-line arguments and started from different working > directories), on hardware with 4 CPUs visible to OpenBSD (quad-core Intel > i7-8650U processor; hyperthreading is disabled both in the BIOS and by > default in OpenBSD). Of those 5 processes, 3 are at 'nice 20', and the > other 2 are at 'nice 10'. I expected the 2 'nice 10' processes to each > get more CPU time than the 3 'nice 20' processes, but 'top -S -i -s1' > shows exactly the opposite behavior: the 3 'nice 20' processes are each > getting MORE CPU time (about 100% of a CPU each) than the 2 'nice 1 > ' processes (about 50% of a CPU each): > > load averages: 5.04, 4.99, 4.04 gold.bkis-orchard.net > 18:02:38 > 176 processes: 4 running, 168 idle, 4 on processor up 7 days, > 17:40 > CPU0: 0.0% user, 97.0% nice, 0.0% sys, 0.0% spin, 3.0% intr, 0.0% idle > CPU1: 1.0% user, 99.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle > CPU2: 0.0% user, 100% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle > CPU3: 1.0% user, 99.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle > Memory: Real: 5686M/13G act/tot Free: 1929M Cache: 6785M Swap: 0K/34G > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 95910 jonathan 104 20 39M 42M onproc/3 -17:38 99.02% smp-O3 > 58006 jonathan 104 20 39M 42M run/2 -42:45 98.97% smp-O3 > 63085 jonathan 104 20 39M 42M run/1 -12:39 97.66% smp-O3 > 36985 jonathan 84 10 21M 24M onproc/0 - 5:57 49.66% smp-O3 > 95125 jonathan 84 10 21M 24M run/0 -11:53 49.32% smp-O3 > 64031 _firefox 280 959M 1057M run/2 -63:28 0.83% > firefox-esr > 77428 _firefox 20 1381M 1355M sleep/2 poll179:14 0.10% > firefox-esr > > Am I missing something obvious? > > -- > -- "Jonathan Thornburg [remove color- to reply]" >on the west coast of Canada, eh? >"There was of course no way of knowing whether you were being watched > at any given moment. How often, or on what system, the Thought Police > plugged in on any individual wire was guesswork. It was even conceivable > that they watched everybody all the time." -- George Orwell, "1984" > Are youre processes multithreaded?? Check with top -H. -Otto
has the definition of 'nice' changed?
I've just noticed something odd about the scheduling of processes with varying 'nice' values (7.0-stable/amd64, GENERIC.MP): it appears that processes with 'nice 20' are given more favorable scheduling than those with 'nice 10', which is exactly the opposite of what I'd expect based on the man page for setpriority(2), "lower priorities cause more favorable scheduling" (and longstanding Unix experience). In more detail: Right now I have 5 CPU-bound processes running (all the same binary, but with different command-line arguments and started from different working directories), on hardware with 4 CPUs visible to OpenBSD (quad-core Intel i7-8650U processor; hyperthreading is disabled both in the BIOS and by default in OpenBSD). Of those 5 processes, 3 are at 'nice 20', and the other 2 are at 'nice 10'. I expected the 2 'nice 10' processes to each get more CPU time than the 3 'nice 20' processes, but 'top -S -i -s1' shows exactly the opposite behavior: the 3 'nice 20' processes are each getting MORE CPU time (about 100% of a CPU each) than the 2 'nice 1 ' processes (about 50% of a CPU each): load averages: 5.04, 4.99, 4.04 gold.bkis-orchard.net 18:02:38 176 processes: 4 running, 168 idle, 4 on processor up 7 days, 17:40 CPU0: 0.0% user, 97.0% nice, 0.0% sys, 0.0% spin, 3.0% intr, 0.0% idle CPU1: 1.0% user, 99.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle CPU2: 0.0% user, 100% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle CPU3: 1.0% user, 99.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 0.0% idle Memory: Real: 5686M/13G act/tot Free: 1929M Cache: 6785M Swap: 0K/34G PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 95910 jonathan 104 20 39M 42M onproc/3 -17:38 99.02% smp-O3 58006 jonathan 104 20 39M 42M run/2 -42:45 98.97% smp-O3 63085 jonathan 104 20 39M 42M run/1 -12:39 97.66% smp-O3 36985 jonathan 84 10 21M 24M onproc/0 - 5:57 49.66% smp-O3 95125 jonathan 84 10 21M 24M run/0 -11:53 49.32% smp-O3 64031 _firefox 280 959M 1057M run/2 -63:28 0.83% firefox-esr 77428 _firefox 20 1381M 1355M sleep/2 poll179:14 0.10% firefox-esr Am I missing something obvious? -- -- "Jonathan Thornburg [remove color- to reply]" on the west coast of Canada, eh? "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
Re: How to disable httpd's default
You can make a rewrite to redirect all defaults to your main site (either
https or non-https).
ありがとう
えりな
On Fri, Jan 14, 2022 at 7:59 AM wrote:
> I would like to avoid httpd giving anything if a user types in the IP
> address of the server.
>
> At first I just made an empty page, which is fine for port 80, but if
> the user then types https://xxx.xxx.xxx.xxx, then the certificate for a
> domain shows, which doesn't fit the IP address.
>
> Is there some way to do something like:
>
> server "default" {
> listen on * port 80
> listen on * port 443
> block drop
> }
>
> And then only serve specific domains?
>
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
Hey, On 1/13/22 19:18, Crystal Kolipe wrote: Well, I can connect to his server using: openssl s_client -starttls smtp -connect mail.unglaub.at:25 The handshake completes and I'm able to issue smtp commands. However smtpd always reports that opportunistic TLS failed, and downgrades to plaintext. when you connect to the server, can you do the SMTP dialog? I tried it on my server and other instances running OpenSMTPd and i get the following error: $ openssl s_client -starttls smtp -connect mail.unglaub.at:25 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = storm-peaks.northrend.azeroth.wow-data.net verify return:1 --- Certificate chain 0 s:CN = storm-peaks.northrend.azeroth.wow-data.net i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -BEGIN CERTIFICATE- XXX -END CERTIFICATE- subject=CN = storm-peaks.northrend.azeroth.wow-data.net issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5457 bytes and written 420 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 250 HELP EHLO unglaub.at 250-storm-peaks.northrend.azeroth.wow-data.net Hello unglaub.at [2001:871:210:554:6c50:40ef:c73c:d401], pleased to meet you 250-8BITMIME 250-ENHANCEDSTATUSCODES 250-SIZE 83886080 250-DSN 250 HELP MAIL FROM: 250 2.0.0 Ok RCPT TO: RENEGOTIATING 139809772520832:error:1420410A:SSL routines:SSL_renegotiate:wrong ssl version:../ssl/ssl_lib.c:2142: Are the last two lines expected behavour? I get then on IPv4 and IPv6. Someone else beeing so kind trying to debug this send me something similar. I am shorting it down to the error itself: RENEGOTIATING 139809772520832:error:1420410A:SSL routines:SSL_renegotiate:wrong ssl version:../ssl/ssl_lib.c:2142: Greetings Leo
Re: Error on xenocara.tar.gz extraction
On Thu, Jan 13, 2022 at 06:40:17PM -, Stuart Henderson wrote: > > I recommend you use cvs to fetch the ports tree. > > ports.tar.gz does not quite contain all the files because > some have names which are too long for the format used > by tar(1). > I have always used dump/restore to duplicate file systems because of that problem with tar. But if ports.tar.gz is incomplete, why is it available under snapshots? Does using it followed by cvs up fix the problem? If so, I will modify the program I use for updating to a -current ports tree. I don't use src or xenocara anymore, but if I remember correctly (I might not), I was told that cvs up didn't always bring in a good tree with an existing tree. That was a long time ago. Is there a reason that tar isn't changed to deal with the name length problem? I can guess some possible reasons, but I have no idea if they are true. -- Chris Bennett
Re: HW raid adapter - Adaptec 8405 SGL
Hi, Nick Holland wrote on Thu, Jan 13, 2022 at 11:30:58AM -0500: > On 1/13/22 5:58 AM, Stuart Henderson wrote: >> On 2022-01-13, Aleksander Dzierżanowski wrote: >>> Is 'Adaptec 8405 SGL' hardware raid controller working under OpenBSD? >>> I saw there is *some* Adaptec support, but the model is not listed >>> explicitly. >>> Please advise if I should try to rent a dedicaated server with such >>> card or simply avoid this configuration. >> Avoid. >> Look for mfii for fast/advanced RAID or maybe mpii for something more >> basic. > Yeah, you don't want to use Adaptec for anything other than maybe > leveling your table. > > Consolidation of old posts into one spot here: > https://nickh.org/warstories/adaptec.html That war story is from 2009/2010, around the time when Adaptec went out of business in 2010, but Adaptec has already been a terrible choice for at least half a decade before that. Here is my own war story: https://marc.info/?l=openbsd-misc=110384546229848 (2004-12-23) ... then follow the thread to ... https://marc.info/?l=openbsd-misc=110417903607462 https://marc.info/?l=openbsd-misc=110521055729466 ... If finally ends here: https://marc.info/?l=openbsd-misc=110540361502637 (2005-01-10) Adaptec tells me in direct email: "As you know it is not supported in FreeBSD officially and we appreciate your offering to test the firmware but at this time there is no plan to support FreeBSD or OpenBSD yet." Then, another try a few months later: https://marc.info/?l=openbsd-misc=80290020263 (2005-03-26) https://marc.info/?l=openbsd-misc=80845207030 (2005-03-26) (Same problems under Linux as under OpenBSD) ... https://marc.info/?l=openbsd-misc=111938104307414 (2005-06-21) (Full summary of all the problems) https://marc.info/?l=openbsd-misc=112749851526934 (2005-09-23) (Note this is 3/4ers of a year after initially finding the problems and after switching to completely different hardware except for keeping the AAC card only, and after switching to Linux): "I'm holding my breath and trying not to touch it any more." Four years later: https://marc.info/?l=openbsd-misc=125779509813346 (2009-11-09) "Trash your aac(4) hardware and use softraid(4). At least that's what i'm doing right now. In a nutshell: insufficient docs, thus incomplete support; buggy firmware, thus unreliable with any operating system; Adaptec does not want customers using free software in the full sense of the word. They do write huge Linux drivers covering up the worst bugs in scary ways, but management is only provided by an unwieldy non-standard vendor-supplied Linux-only interactive stand-alone tool, and there is no bioctl(8) support." At that point, continue with Nick's story. Yours, Ingo
Re: Error on xenocara.tar.gz extraction
On 2022-01-13, Rob Whitlock wrote: > As another issue, extracting ports.tar.gz as a non-privileged user in /usr, > as described in the document whose address is given above, results in > failure due to lack of permission, as a normal user does not have access to > create the /usr/ports directory. I recommend you use cvs to fetch the ports tree. ports.tar.gz does not quite contain all the files because some have names which are too long for the format used by tar(1).
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
On Thu, Jan 13, 2022 at 05:25:41PM +, Stuart Henderson wrote: > On 2022/01/13 18:05, Leo Unglaub wrote: > > Hey, > > > > On 11/01/2022 21:28, Stuart Henderson wrote: > > > I bet it is MTU related. Try lowering MTU on that interface (you > > > cannot do it separately for IPv4 and IPv6 so it will change both, > > > but that's not likely to be a problem) and get someone who has > > > seen the problems to re-test. > > > > thank you so much for your answer. I would have never ever thought about the > > MTU in this case. I used the default 1500. I talked to the technical support > > from the datacenter (Hetzner Online) and they asured me that 1500 is > > correct. > > > > However, i have set the value to 1400 and asked some people who had the > > issue to re-test it. I will post the results of the test here so other > > people can find them via a search engine. > > > > Thank you so much, very kind of you! > > The possible issue is that many people (especially people connecting > over tunnels, but also those on pppoe) are on lower MTUs than this. > Normally this is OK as fragmentation-needed messages will sort things > out but sometimes firewalls are not be configured to pass these which > will cause problems. If that _is_ what's happening then there are > other ways to fix it but changing MTU is often the easiest one that > you can do yourself. Well, I can connect to his server using: openssl s_client -starttls smtp -connect mail.unglaub.at:25 The handshake completes and I'm able to issue smtp commands. However smtpd always reports that opportunistic TLS failed, and downgrades to plaintext.
Re: Error on xenocara.tar.gz extraction
It is just a warning, you can ignore it. I am not going to change my processes to ship a tar file without "." Rob Whitlock wrote: > Attempting to extract xenocara.tar.gz while avoiding root proviliges as > described here https://www.openbsd.org/faq/faq5.html#wsrc, I ran into an > error, shown below: > > 0 thinkpad$ pwd > /usr/xenocara > 0 thinkpad$ ls -a > > . .. > 0 thinkpad$ tar xzf /home/rob/openbsd_files/7.0/xenocara.tar.gz > > tar: Access/modification time set failed on: .: Operation not permitted > 1 thinkpad$ ls -a > . 3RDPARTY Makefile data docfont share > .. CVSREADME dist driver libutil > .gitignore MODULESappdistribetcproto xserver > 0 thinkpad$ cd .. > 0 thinkpad$ ls -ld xenocara > drwxrwxr-x 16 root wsrc512 Jan 12 21:43 xenocara > 0 thinkpad$ id > uid=1001(rob) gid=1001 groups=1001, 0(wheel), 9(wsrc) > 0 thinkpad$ > > Running ktrace on tar shows that tar is trying to set the mtime of ., which > corresponds to /usr/xenocara, with the function futimens, which fails. > According to the man page for futimens, if the times argument is non-NULL, > which is the case here, then the caller must be the owner of the file or > the superuser. For an unprivileged user, this is not the case, as, although > /usr/xenocara has group wsrc, it has owner root. > > Running tar tzf xenocara.tar.gz shows an entry for . which seems to be > causing this problem. If you instead run tar xzf xenocara.tar.gz -s > '/^\.$//' to omit only the . entry when extracting, there is no more error. > There is a side effect to adding this -s option, which is that > /usr/xenocara's mtime gets updated to the time the tarball extraction took > place, as opposed to the time that was recorded for . in the tarball. I > don't know whether updating /usr/xenocara to the mtime that was recorded in > the tarball was intentional behavior or not. > > If updating the mtime of /usr/xenocara was not intentional behavior, it > would seem to me that the fix for this problem would be to not include the > . directory when making the tarball xenocara.tar.gz. I was unable to locate > any code that was responsible for creating xenocara.tar.gz so I have not > included a diff. If anybody could tell me where that code is then that > would be appreciated. > > As another issue, extracting ports.tar.gz as a non-privileged user in /usr, > as described in the document whose address is given above, results in > failure due to lack of permission, as a normal user does not have access to > create the /usr/ports directory. > > I am running a snapshot of OpenBSD 7.0 that is only a few days old.
Re: Error on xenocara.tar.gz extraction
i think u need to do as root or configure doas to perform privleged operation... On Thu 13 Jan 2022, 17:26 Rob Whitlock, wrote: > Attempting to extract xenocara.tar.gz while avoiding root proviliges as > described here https://www.openbsd.org/faq/faq5.html#wsrc, I ran into an > error, shown below: > > 0 thinkpad$ pwd > /usr/xenocara > 0 thinkpad$ ls -a > > . .. > 0 thinkpad$ tar xzf /home/rob/openbsd_files/7.0/xenocara.tar.gz > > tar: Access/modification time set failed on: .: Operation not permitted > 1 thinkpad$ ls -a > . 3RDPARTY Makefile data docfont share > .. CVSREADME dist driver libutil > .gitignore MODULESappdistribetcproto xserver > 0 thinkpad$ cd .. > 0 thinkpad$ ls -ld xenocara > drwxrwxr-x 16 root wsrc512 Jan 12 21:43 xenocara > 0 thinkpad$ id > uid=1001(rob) gid=1001 groups=1001, 0(wheel), 9(wsrc) > 0 thinkpad$ > > Running ktrace on tar shows that tar is trying to set the mtime of ., which > corresponds to /usr/xenocara, with the function futimens, which fails. > According to the man page for futimens, if the times argument is non-NULL, > which is the case here, then the caller must be the owner of the file or > the superuser. For an unprivileged user, this is not the case, as, although > /usr/xenocara has group wsrc, it has owner root. > > Running tar tzf xenocara.tar.gz shows an entry for . which seems to be > causing this problem. If you instead run tar xzf xenocara.tar.gz -s > '/^\.$//' to omit only the . entry when extracting, there is no more error. > There is a side effect to adding this -s option, which is that > /usr/xenocara's mtime gets updated to the time the tarball extraction took > place, as opposed to the time that was recorded for . in the tarball. I > don't know whether updating /usr/xenocara to the mtime that was recorded in > the tarball was intentional behavior or not. > > If updating the mtime of /usr/xenocara was not intentional behavior, it > would seem to me that the fix for this problem would be to not include the > . directory when making the tarball xenocara.tar.gz. I was unable to locate > any code that was responsible for creating xenocara.tar.gz so I have not > included a diff. If anybody could tell me where that code is then that > would be appreciated. > > As another issue, extracting ports.tar.gz as a non-privileged user in /usr, > as described in the document whose address is given above, results in > failure due to lack of permission, as a normal user does not have access to > create the /usr/ports directory. > > I am running a snapshot of OpenBSD 7.0 that is only a few days old. >
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
On 2022/01/13 18:05, Leo Unglaub wrote: > Hey, > > On 11/01/2022 21:28, Stuart Henderson wrote: > > I bet it is MTU related. Try lowering MTU on that interface (you > > cannot do it separately for IPv4 and IPv6 so it will change both, > > but that's not likely to be a problem) and get someone who has > > seen the problems to re-test. > > thank you so much for your answer. I would have never ever thought about the > MTU in this case. I used the default 1500. I talked to the technical support > from the datacenter (Hetzner Online) and they asured me that 1500 is > correct. > > However, i have set the value to 1400 and asked some people who had the > issue to re-test it. I will post the results of the test here so other > people can find them via a search engine. > > Thank you so much, very kind of you! The possible issue is that many people (especially people connecting over tunnels, but also those on pppoe) are on lower MTUs than this. Normally this is OK as fragmentation-needed messages will sort things out but sometimes firewalls are not be configured to pass these which will cause problems. If that _is_ what's happening then there are other ways to fix it but changing MTU is often the easiest one that you can do yourself.
Re: OpenSMTPd: Unable to use TLS/SSL over IPv6
Hey, On 11/01/2022 21:28, Stuart Henderson wrote: I bet it is MTU related. Try lowering MTU on that interface (you cannot do it separately for IPv4 and IPv6 so it will change both, but that's not likely to be a problem) and get someone who has seen the problems to re-test. thank you so much for your answer. I would have never ever thought about the MTU in this case. I used the default 1500. I talked to the technical support from the datacenter (Hetzner Online) and they asured me that 1500 is correct. However, i have set the value to 1400 and asked some people who had the issue to re-test it. I will post the results of the test here so other people can find them via a search engine. Thank you so much, very kind of you!
Error on xenocara.tar.gz extraction
Attempting to extract xenocara.tar.gz while avoiding root proviliges as described here https://www.openbsd.org/faq/faq5.html#wsrc, I ran into an error, shown below: 0 thinkpad$ pwd /usr/xenocara 0 thinkpad$ ls -a . .. 0 thinkpad$ tar xzf /home/rob/openbsd_files/7.0/xenocara.tar.gz tar: Access/modification time set failed on: .: Operation not permitted 1 thinkpad$ ls -a . 3RDPARTY Makefile data docfont share .. CVSREADME dist driver libutil .gitignore MODULESappdistribetcproto xserver 0 thinkpad$ cd .. 0 thinkpad$ ls -ld xenocara drwxrwxr-x 16 root wsrc512 Jan 12 21:43 xenocara 0 thinkpad$ id uid=1001(rob) gid=1001 groups=1001, 0(wheel), 9(wsrc) 0 thinkpad$ Running ktrace on tar shows that tar is trying to set the mtime of ., which corresponds to /usr/xenocara, with the function futimens, which fails. According to the man page for futimens, if the times argument is non-NULL, which is the case here, then the caller must be the owner of the file or the superuser. For an unprivileged user, this is not the case, as, although /usr/xenocara has group wsrc, it has owner root. Running tar tzf xenocara.tar.gz shows an entry for . which seems to be causing this problem. If you instead run tar xzf xenocara.tar.gz -s '/^\.$//' to omit only the . entry when extracting, there is no more error. There is a side effect to adding this -s option, which is that /usr/xenocara's mtime gets updated to the time the tarball extraction took place, as opposed to the time that was recorded for . in the tarball. I don't know whether updating /usr/xenocara to the mtime that was recorded in the tarball was intentional behavior or not. If updating the mtime of /usr/xenocara was not intentional behavior, it would seem to me that the fix for this problem would be to not include the . directory when making the tarball xenocara.tar.gz. I was unable to locate any code that was responsible for creating xenocara.tar.gz so I have not included a diff. If anybody could tell me where that code is then that would be appreciated. As another issue, extracting ports.tar.gz as a non-privileged user in /usr, as described in the document whose address is given above, results in failure due to lack of permission, as a normal user does not have access to create the /usr/ports directory. I am running a snapshot of OpenBSD 7.0 that is only a few days old.
Re: HW raid adapter - Adaptec 8405 SGL
On 1/13/22 5:58 AM, Stuart Henderson wrote: On 2022-01-13, Aleksander Dzierżanowski wrote: Hi, Is 'Adaptec 8405 SGL' hardware raid controller working under OpenBSD? I saw there is *some* Adaptec support, but the model is not listed explicitly. Please advise if I should try to rent a dedicaated server with such card or simply avoid this configuration. Avoid. Look for mfii for fast/advanced RAID or maybe mpii for something more basic. Yeah, you don't want to use Adaptec for anything other than maybe leveling your table. Consolidation of old posts into one spot here: https://nickh.org/warstories/adaptec.html Nick.
Re: HW raid adapter - Adaptec 8405 SGL
On 2022-01-13, Aleksander Dzierżanowski wrote: > Hi, > > Is 'Adaptec 8405 SGL' hardware raid controller working under OpenBSD? > I saw there is *some* Adaptec support, but the model is not listed explicitly. > Please advise if I should try to rent a dedicaated server with such card > or simply avoid this configuration. Avoid. Look for mfii for fast/advanced RAID or maybe mpii for something more basic.
Re: Problem with some pf table defined outside of an anchor
Uhhmm …. But this is not the case I have only referenced the
table once. Complete rules:
table persist counters
#
# Specific options for exposed services
#
exposed_tcp = "(max-src-conn 10, max-src-conn-rate 15/5, overload
flush global)"
exposed_udp = "(max-src-conn 30, max-src-conn-rate 10/1, overload
flush global)"
#
#
# Default policy rules
#
#
# Block brute force access
block quick log from label "Block access from bruteforce hosts"
#---
# Policy for inbound connections to egress interface
#---
#
# Group of rules for exposed public services
#
anchor inet from ! to (carp1) tag inet-to-enc {
pass in log (all, to pflog1) proto udp to port $pub_port keep state
$exposed_udp rdr-to $encgw01 port $pub_port
}
> On 12 Jan 2022, at 18:50, Marin BERNARD wrote:
>
> Hi,
>
> Your anchor is probably defined twice, once in the main ruleset, and
> once more in the context of the 'pub-network/_2' anchor.
>
> In such case a warning is shown to let you know that this is not
> recommended practice.
>
> From pfctl(8) man page (http://man.openbsd.org/pfctl#a):
>
>> When a rule referring to a table is loaded in an anchor, the rule
>> will use the private table if one is defined, and then fall back to
>> the table defined in the main ruleset, if there is one. This is
>> similar to C rules for variable scope. It is possible to create
>> distinct tables with the same name in the global ruleset and in an
>> anchor, but this is often bad design and a warning will be issued in
>> that case.
>
> ‐‐‐ Original Message ‐‐‐
>
> Le mercredi 12 janvier 2022 à 11:58, Carlos Lopez a
> écrit :
>
>> Hi all,
>>
>
>> I have a strange issue when I use a pf table inside an anchor. Error
>> returned is:
>>
>
>> pfctl: warning: table already defined in anchor "pub-network/_2”
>>
>
>> Table is defined in global pf.conf file. In pf.conf I have
>> defined some anchors by interface, like this:
>>
>
>> Group of rules for public network
>> =
>>
>
>> anchor "pub-network" on egress
>>
>
>> load anchor pub-network from "/etc/fwrules/publan.conf”
>>
>
>> Inside public.conf I have the rule that returns this warning:
>>
>
>> exposed_tcp = "(max-src-conn 10, max-src-conn-rate 15/5, overload
>> flush global)”
>>
>
>> anchor inet from ! to (carp1) tag inet-to-enc {
>>
>
>>pass in log (all, to pflog1) proto tcp to port $my_port keep state
>> $exposed_tcp rdr-to $encgw01 port $my_port
>>
>
>>
>
>> }
>>
>
>> How can I fix it? Or maybe am I doing some mistake?
>
Re: Unable to decrypt a file with LibreSSL
On Thu, Jan 13, 2022 at 03:50:15AM +, Ricky Cintron wrote: > ? Original Message ? > > On Wednesday, January 12th, 2022 at 1:14 PM, Crystal Kolipe > wrote: > > > On Wed, Jan 12, 2022 at 08:56:19PM +, Ricky Cintron wrote: > > > > > As the subject reads, I am suddenly unable to decrypt a file that I > > > encrypted > > > > > > with LibreSSL. When I try, I get the following message: > > > > > > bad decrypt > > > > > > 11957684617984:error:06FFF064:digital envelope routines:CRYPTO_internal: \ > > > > > > bad decrypt:/usr/src/lib/libcrypto/evp/evp_enc.c:549: > > > > > > I haven't been able to figure out the cause, so I'm looking for guidance. > > > > That error message is very non-specific, and can have many causes. > > > > > Some more information: > > > > > > I encrypted this file around September or October of 2021 using the > > > following > > > > > > command: > > > > > > $ openssl aes-256-cbc -e -a -salt -in -out > > > > > > And to decrypt it, I use > > > > > > $ openssl aes-256-cbc -d -a -in -out > > > > > > I also configured neovim to allow me to open and overwrite the file > > > > > > transparently, using an autocmd group, which has worked without issue. I > > > > > > upgraded my -current system on Saturday, January 8 (OpenBSD 7.0-current > > > > > > (GENERIC.MP) #242: Sat Jan 8 12:33:38 MST 2022), and I was able to > > > decrypt it > > > > > > with neovim on Monday, but I didn't modify/write the file (it was last > > > modified > > > > > > on Dec 20 2021). I attempted to open the file again in neovim on Tuesday, > > > but > > > > > > was presented with the 'bad decrypt' message instead. I initially tried in > > > > > > neovim, but I'm seeing the same message when I use the openssl command > > > (above) > > > > > > directly. > > > > Just to confirm, you were able to decrypt it once after the system upgrade > > on > > > > the 8th, but subsequently failed, the file itself has, (apparently), not > > been > > > > modified, and you have not made any other changes to the system? > > > > When you attempt to decrypt from the command line, do you get partial > > decrypted > > > > output, I.E. the beginning of the expected plaintext? A truncated ciphertext > > > > can cause the 'bad decrypt' error, but the start of the file will be > > correctly > > > > decrypted. > > > > Since your encrypted file is base64 encoded, have you looked at it and > > checked > > > > that it's not corrupted? For example, 512 bytes of all 0x00 or 0xFF > > somewhere > > > > in it would obviously be suspicious. > > > > Are you absolutely sure that you are using the correct passphrase? > > > > Finally, and this is NOT your problem, but I'm mentioning it for the > > benefit of > > > > anybody searching the mailing list archives with a similar problem: a > > number of > > > > years ago the default message digest for OpenSSL changed, (from md5 to > > sha256), > > > > and files encrypted with the old md will need -md md5 specified on the > > command > > > > line to decrypt them with current versions of OpenSSL or LibreSSL. But that > > is > > > > not the issue here. > > I was going to respond to each of your questions individually, but when I > went to > copy/paste the additional text that is printed along with the 'bad decrypt' > message to stdout (when not using the -out option), my muscle memory > apparently > kicked in just enough to hint that I was possibly messing up the password. So > yeah, I can confirm that, for some absurd reason, I had mixed up some symbols > in > the password, and after correcting it, I am now able to decrypt the file > again. > That's two days of attempting the wrong password. Just stunning. :| It's nowhere near as uncommon as you think. We once had somebody bring us a file that "wouldn't decrypt" with the correct passphrase. Suspecting that it was a typo made whilst encrypting, we wrote a program to brute-force the possible key- strokes around the given keys. For example, if the first character was supposedly 'f', we tested e, r, t, d, f, g, c, v, and b in that position. With a few optimisations to test what seemed the most likely combinations first, we found the actual passphrase fairly quickly. Comparing the two, we concluded that he had offset the characters typed with the left hand by one position to the right. Luckily in your case, the typo was being made at the point of decryption. If the way you've got neovim set up is that it asks you for the passphrase each time, for both decryption and later encryption of the saved file, and if you intend to use the same passphrase each time, you might want to add an extra step to check that the original file can still be decrypted with the new passphrase you just entered before overwriting it, thereby checking that you entered it correctly. I.E. * Ask for decryption passphrase and decrypt original ciphertext * Edit plaintext version and save modified plaintext * Ask for
