Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Thu, Jan 28, 2021 at 4:38 AM Nick Holland wrote: > -a at the boot prompt is my thought, too...but the little bit of your > dmesg that you show seems to indicate you are not seeing the encrypted > drive handled by in softraid at all. So I have my concerns this won't > do much but delay the panic (the kernel's panic. Too late for your > panic, I'm sure). > I tried booting using -a or -s, but I have no luck. When I use -a it gets to the moment where it asks for the root device but the keyboard is dead, I can't do anything. And when using -s it just hangs with the previous panic message. > > If this doesn't work for you, I'd start by booting off a bsd.rd (USB, > CDROM, network, whatever) and looking around a bit. What does the > fdisk of your physical drive look like? Is your OpenBSD partition > still there? If not, recreate it (hopefully you either used the > defaults or remember what you did). All that really matters is the > starting sector (probably 64 assuming MBR. UEFI is 1024, iirc, but > I'm too lazy to look this up right now. Dammit, no I'm not, yes, > probably 1024, but I'm DEFINITELY not looking to see if that's a > hard number or if there are things that cause it to move around). > > After the fdisk partitions, look at the disklabel in on the physical > drive -- should be one big RAID partition as 'a' and type RAID. > > I looked at the softraid partition and everything seems fine. As I mentioned I see it as a 'a' RAID partition. Then I do a bioctl on it and I can access it and see al the other partitions 'a-j' . I did an fsck -p on all of them and I get no errors. I even mount them to see if everything is ok and I managed to get the work done in '/home', but that is all. When I reboot nothing works. > I am kinda suspicious that the bioctl command you gave was not the > culprit in this situation, but something else in your script. > > Actually in the moment I was not running the script. I was doing some tests and I could no longer access the sd1 which was used by a previous bioctl attempt. So i tried to do a 'bioctl -d', but by mistake instead of sd1 I did it on sd0. All froze and I had to do a hard reset. > As for safeguards...Well, from personal experience recently, I can > *assure* you I understand the first response when something goes > horribly wrong and your finger is the one on the (virtual) trigger > is, "Why wasn't there a safeguard??". I get that, and I bet mine > was a bigger oops than yours. But realistically, there are an > almost unlimited number of ways to hurt yourself, and a much smaller > number of ways to do things right, and often what to person A is > a horrible mistake, person B needs as a way to solve a big problem. > I have often needed to use an OS like OpenBSD to clean up messes in > other OSs because the safeguards in the other OS prevented me from > doing what I needed to do. So yes, I understand, but no, I don't > want a "are you sure?" on every step of everything that could cause > an "event". > > I understand the point and maybe it is ok this way. Actually that is why I am creating this scripts --- to check before doing anything that I am not trying to modify the 'root' disk. > And think how much you just learned about the value of good backups... > > I learned this lesson a long time ago, on my beginner Linux years. Now, is just a reminder. Thank for your answer and help and I appreciate any further hints. > Nick. >
Re: iked(8) CREATE_CHILD_SA successful at initial connection time, fail at rekey interval
On Wed, Jan 27, 2021 at 3:28 AM Tobias Heider wrote: > looks like a PFS problem. > > Here's where it fails: > > Jan 26 18:48:30 strannik iked[41041]: spi=0x6184b254a8e8d175: > > ikev2_log_proposal: ESP #1 DH=MODP_2048 > > At the moment, PFS groups must be enabled manually. > Try this: > > ikev2 "home" passive esp inet \ > from 10.0.10.0/24 to 10.0.1.0/24 \ > from 10.0.10.0/24 to 10.0.4.0/24 \ > from 10.0.10.0/24 to 10.0.7.0/24 \ > local responder peer initiator \ > childsa group modp2048 \ > srcid "/CN=responder" dstid "/CN=initiator" Worked like a charm, of course. Thank you! I recall now having seen this and not understood it at the time: "For IKEv2 the keys for the first CHILD_SA, created implicitly with the IKE_SA, will always be derived from the IKE_SA's key material. So any DH group set here only applies when the CHILD_SA is later rekeyed or created with a CREATE_CHILD_SA exchange on an existing IKE_SA. A proposal mismatch may, therefore, not immediately be detected when the SA is established, but may later cause rekeying to fail." -- Darren Spruell phatbuck...@gmail.com
Re: OpenBSD (memory management) performance issues
On Wed, Jan 27, 2021 at 08:39:46AM +0100, Otto Moerbeek wrote:
> On Tue, Jan 26, 2021 at 04:08:40PM +, Marek Klein wrote:
>
> > Hi,
> >
> > We are working on an appliance like product that is based on OpenBSD.
> > Recently we found out that our performance critical C++ program is
> > ~2.5 times slower on OpenBSD compared to Ubuntu 20.04.
> >
> > The program basically just reads data from stdin, does some
> > transformation of the data, and returns the result on stdout, thus
> > the program does not perform any further I/O operations nor interacts
> > with other programs. We extensively use the C++ standard library string
> > class for manipulation of data.
> >
> > We started searching for the reason, and eliminated I/O as a factor.
> > During some experiments we found out that one, perhaps not the only
> > one, factor is OpenBSD's memory management. To test this assumption we
> > wrote a simple program that allocates and frees memory in a loop.
> > Something like:
> >
> > for (...) {
> > void *buffer = malloc(...);
> > ...
> > free(buffer);
> > }
> >
> > We compiled it on OpenBSD with clang
> > $ /usr/bin/c++ --version
> > OpenBSD clang version 10.0.1
> > Target: amd64-unknown-openbsd6.8
> > Thread model: posix
> > InstalledDir: /usr/bin
> >
> > using options '-O3 -DNDEBUG -std=gnu++11' and ran it without memory
> > junking.
> >
> > $ time MALLOC_OPTIONS=jj ./memory_allocs --cycles 123456789 --size 1024
> >
> > real0m27.218s
> > user0m27.220s
> > sys 0m0.020s
> >
> > We compiled the same program on Ubuntu 20.04 with g++
> > $ /usr/bin/c++ --version
> > c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> >
> > using the same options '-O3 -DNDEBUG -std=gnu++11'
> >
> > $ time ./memory_allocs --cycles 123456789 --size 1024
> >
> > real0m1,920s
> > user0m1,915s
> > sys 0m0,004s
> >
> > Both systems were tested in the same virtualized environment (VSphere),
> > thus we can assume the "hardware" is the same.
> >
> > Given the virtual environment, the tests might not be scientifically
> > the best choice, but they serve the observation well enough. We
> > actually ruled out virtualization as a cause in other tests.
>
> Short story: the slowness is because you get more security.
>
> Somewhat longer story: depending on the size if the allocation actual
> unmaps take place on free. This will catch use-after-free always. For
> smaller allocations, caching takes place, sadly you did not tell us
> how big the total of your allocations are. So I cannot predict if
> enlargering the cache will help you.
>
> Now the differnence is quite big so I like to know what you are doing
> exactly in your test program. Please provide the full test porogram
> so I can take a look.
>
> >
> > What other options are there we could try in order to speed the memory
> > management up?
>
> Some hintss: allocate/free less, use better algorithms that do not
> allocate as much. With C++ make sure your code uses moves of objects
> instead of copies whenever possible. Use reserve() wisely. If all else
> fails you might go for custom allocaters, but you will loose security
> features.
>
> -Otto
>
> >
> > Also are there any other known areas, for CPU bound processing, where
> > OpenBSD performs worse than other "common" platforms?
> >
> > Cheers,
> > Marek
> >
>
To reply to myself.
Be VERY careful when drawing conclusions from these kinds of test
programs. To demonstrate, the loop in the test program below gets
compiled out by some compilers with some settings.
So again, please provide your test program.
-Otto
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
size_t count, sz, i;
char *p;
const char *errstr;
count = strtonum(argv[1], 0, LONG_MAX, &errstr);
if (errstr)
errx(1, "%s: %s", argv[1], errstr);
sz = strtonum(argv[2], 0, LONG_MAX, &errstr);
if (errstr)
errx(1, "%s: %s", argv[2], errstr);
printf("Run with %zu %zu\n", count, sz);
for (i = 0; i < count; i++) {
p = malloc(sz);
if (p == NULL)
err(1, NULL);
*p = 1;
free(p);
}
}
Re: OpenSMTPD is not sending e-mail.
Diana Eichert wrote on Wed [2021-Jan-27 08:30:34 -0700]: > On Tue, Jan 26, 2021 at 5:25 PM latincom wrote: > > > > Hello misc@ > > > > I can not believe that the solution has been to open port 25, Vultr rent > > servers whit port 25 closed! > > > > Thanks so much to Stuart Henderson for the solution. > > Yes Vultr and many other VM providers block tcp port 25 by default, > however most will open it up if you request it. Vultr isn't my only VPS provider but I definitely recommend them. When I submitted a ticket requesting they open port 25, they responded within minutes on a weekend. BTW that info about 25 (and a few other ports I believe) being blocked by default is somewhere on their website. Mitch
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On 1/27/21 1:45 PM, Samarul Meu wrote: mie., 27 ian. 2021, 20:24 a scris: Ironically this is the same error I have been getting, and recently posted about in the thread "Bootloader on USB stick fails with "root device not found"" ... I read your thread just now. I will try the -a option. Interesting, but I must mention that my OpenBSD is installed on an encrypted partition. -a at the boot prompt is my thought, too...but the little bit of your dmesg that you show seems to indicate you are not seeing the encrypted drive handled by in softraid at all. So I have my concerns this won't do much but delay the panic (the kernel's panic. Too late for your panic, I'm sure). If this doesn't work for you, I'd start by booting off a bsd.rd (USB, CDROM, network, whatever) and looking around a bit. What does the fdisk of your physical drive look like? Is your OpenBSD partition still there? If not, recreate it (hopefully you either used the defaults or remember what you did). All that really matters is the starting sector (probably 64 assuming MBR. UEFI is 1024, iirc, but I'm too lazy to look this up right now. Dammit, no I'm not, yes, probably 1024, but I'm DEFINITELY not looking to see if that's a hard number or if there are things that cause it to move around). After the fdisk partitions, look at the disklabel in on the physical drive -- should be one big RAID partition as 'a' and type RAID. I am kinda suspicious that the bioctl command you gave was not the culprit in this situation, but something else in your script. As for safeguards...Well, from personal experience recently, I can *assure* you I understand the first response when something goes horribly wrong and your finger is the one on the (virtual) trigger is, "Why wasn't there a safeguard??". I get that, and I bet mine was a bigger oops than yours. But realistically, there are an almost unlimited number of ways to hurt yourself, and a much smaller number of ways to do things right, and often what to person A is a horrible mistake, person B needs as a way to solve a big problem. I have often needed to use an OS like OpenBSD to clean up messes in other OSs because the safeguards in the other OS prevented me from doing what I needed to do. So yes, I understand, but no, I don't want a "are you sure?" on every step of everything that could cause an "event". And think how much you just learned about the value of good backups... Nick.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 05:50:07PM +0200, Samarul Meu wrote:
After searching online I discovered this: boot sr0a:/bsd. Now it asks
for
my Passphrase and it starts booting but then it hangs
softraid0 at root
scsibus2 at softraid0: 256 targets
panic: root device (3312a...) not found
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
* 00 0 0x1 0x2000 0kswapper
panic(ff81dff) at panic+0x12a
setroot(80..) at setroot+0xdeb
disconf(1b21..) at diskconf+0x185
main(0,0,0,0,0,80..) at main+0x500
end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
describes the minimum info required inbug reports. Insufficient
info makes it difficult to find and fix bugs.
ddb{0}>
Using a usb drive with *FuguIta* I managed to do a fsck on all partitions
(some errors appeared, but I cleaned them).
I was even able to mount them and everything seems fine, I recovered what I
was working on, but I have no luck in booting. Again and again the above
error.
Ironically this is the same error I have been getting, and recently
posted about in the thread "Bootloader on USB stick fails with "root
device not found"" ...
Re: auto-boot
On 26/1/21 3:04 am, Mihai Popescu wrote: That short with a metallic wire was just for quick check. It is not recommended for prolonged usage! It will block any communication on the RS232 cable. Probably not very healthy for the RS-232 driver either. High-valued resistor is probably a safer bet. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Samarul Meu wrote:
> It showed only this:
>
> open(hd0a:/etc/boot.conf): Invalid argument
> boot>
> cannot open hd0a:/etc/random.seed: Invalid argument
> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
> failed(22). will try /bsd
>
> After searching online I discovered this: boot sr0a:/bsd. Now it asks for
> my Passphrase and it starts booting but then it hangs
>
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> panic: root device (3312a...) not found
> Stopped at db_enter+0x10: popq %rbp
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> * 00 0 0x1 0x2000 0kswapper
> panic(ff81dff) at panic+0x12a
> setroot(80..) at setroot+0xdeb
> disconf(1b21..) at diskconf+0x185
> main(0,0,0,0,0,80..) at main+0x500
> end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
> describes the minimum info required inbug reports. Insufficient
> info makes it difficult to find and fix bugs.
> ddb{0}>
I think I was having the same problem when I changed the passphrase
of my disk. I managed to fix it with installboot(8). You can
access the bug report in here:
https://marc.info/?l=openbsd-bugs&m=161075212820257&w=2
I had the panic with the 6.8-stable device, but the 6.8-current device
was booting just fine. In fact, I've used installboot(8) on that device
while it was running (booted by hand with sr0a:/bsd as you did).
Sincerely,
vejetaryenvampir
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, Jan 27, 2021 at 05:50:07PM +0200, Samarul Meu wrote: > I was playing with some script trying to create an encrypted image and > accidentally I did bioctl -d sd0 where sd0 is the disk with my OpenBSD > install. Of course the system hanged. When I tried to reboot it no longer > ask me for my passphrase. > [...] > Using a usb drive with *FuguIta* I managed to do a fsck on all partitions > (some errors appeared, but I cleaned them). > > I was even able to mount them and everything seems fine, I recovered what I > was working on, but I have no luck in booting. Again and again the above > error. > I am a little puzzled that there is no failsafe mechanism for commands like > bioctl or fdisk on the already mounted disk. For me the obvious think was > that the system complains when trying bioctl -d sd0. Perhaps. But that would require not-trivial WORK, maybe a LOT, which someone would have to DO, probably for FREE. I suspect detaching a running encrypted root disk is somewhat uncharted territory. In a perfect world the same command might've offered a "failsafe" mechanism and performed logout, shutdown, umount and sync and whatnot in the case of an affirmative response, but not in ours. Such a perfect world might not even be preferable given how much added code complexity and size such "failsafe" mechanisms could involve. For now, consider yourself lucky to have recovered your data. That is the most important thing and I'm happy on your behalf to hear that you managed so. Regards
Re: Managed to mess up the system encrypted disk. I can no longer boot.
mie., 27 ian. 2021, 20:24 a scris: > > Ironically this is the same error I have been getting, and recently > posted about in the thread "Bootloader on USB stick fails with "root > device not found"" ... > I read your thread just now. I will try the -a option. Interesting, but I must mention that my OpenBSD is installed on an encrypted partition. >
Re: plugging head phones does not mute speaker
Maurice McCarthy writes: > Sndiod is to be the default method of controliing audio. > Run sndiod and see what sndioctl says. > > doas rcctl enable sndiod > doas rcctl start sndiod > doas sndioctl [...] thanks. this does not solve the problem unfortunately. -- cheers, björn
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Color me surprised...I can't say I've ever tried it to know. Still, rm is a little different to something that's talking directly to a device. On Wed, 27 Jan 2021 at 12:33, Daniel Jakots wrote: > > On Wed, 27 Jan 2021 11:31:13 -0500, Ashton Fagg > wrote: > > > Do you want "rm -rf /" to hold your hand also? > > As a matter of fact, it does :) > https://github.com/openbsd/src/commit/c11d908c7069eb03d103482ce1d0227f3d47b349 >
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, 27 Jan 2021 11:31:13 -0500, Ashton Fagg wrote: > Do you want "rm -rf /" to hold your hand also? As a matter of fact, it does :) https://github.com/openbsd/src/commit/c11d908c7069eb03d103482ce1d0227f3d47b349
Re: Managed to mess up the system encrypted disk. I can no longer boot.
Pressed send too early. It is also worth pointing out that I'm fairly sure every *nix has similar ways to blow your arms and legs off. There's nothing special about OpenBSD or bioctl in that sense. On Wed, 27 Jan 2021 at 11:31, Ashton Fagg wrote: > > On Wed, 27 Jan 2021 at 10:55, Samarul Meu wrote: > > > > I am a little puzzled that there is no failsafe mechanism for commands like > > bioctl or fdisk on the already mounted disk. For me the obvious think was > > that the system complains when trying bioctl -d sd0. > > To be fair, bioctl talks to block I/O devices (i.e. nothing to do with > filesystems). So it is hardly surprising that this can happen > considering that fact. Do you want "rm -rf /" to hold your hand also? > You could also blow away a disk with "dd" if you're not careful - > should that try and preempt you from making a mistake? > > I know that doesn't help you, but I can imagine that's the rationale. > If you want to shoot yourself in the foot, that's just fine.
Re: Managed to mess up the system encrypted disk. I can no longer boot.
On Wed, 27 Jan 2021 at 10:55, Samarul Meu wrote: > > I am a little puzzled that there is no failsafe mechanism for commands like > bioctl or fdisk on the already mounted disk. For me the obvious think was > that the system complains when trying bioctl -d sd0. To be fair, bioctl talks to block I/O devices (i.e. nothing to do with filesystems). So it is hardly surprising that this can happen considering that fact. Do you want "rm -rf /" to hold your hand also? You could also blow away a disk with "dd" if you're not careful - should that try and preempt you from making a mistake? I know that doesn't help you, but I can imagine that's the rationale. If you want to shoot yourself in the foot, that's just fine.
Re: 6.8 and Procmail/Formail: anyone still using them?
On 26/01/2021 10:43 a.m., Austin Hook wrote: Wonder if anyone is still using Procmail/Formail under 6.8 for presorting incoming mail before it hits one's main inbox. Also wondering if folks send the remainimg mail, after filtering, to /var/mail/*user*, or to ~/mbox or to ~mail/mbox. Any advantage to be had, or any mere consensus, regardless of advantages? I also use whitelisting extensively, and any such "From: emailaddresses" get priority. Does anyone else? Myself: Having problems with Procmail/formail, after upgrading from 5.3 to a new server running 6.8. Would like to hear of anyone else's experience. Thanks, Austin Hook Milk River, Alberta Hi, I am using procmail under 6.8 successfully. I did have problems with it when upgrading to (I think) 6.4. If you look for the mail list archives for "OpenBSD 6.4 smtpd local mail delivery missing "From " when .forward (procmail)" My .procmailrc: "|/usr/local/bin/procmail -f -" Not sure if this is your problem or not. But I have quite a large .procmailrc file (200 lines) that makes a historical archive of every incoming email, filtering maillist emails, etc. Thanks, Steve W.
Managed to mess up the system encrypted disk. I can no longer boot.
Hello!
Please help. I really messed up.
I was playing with some script trying to create an encrypted image and
accidentally I did bioctl -d sd0 where sd0 is the disk with my OpenBSD
install. Of course the system hanged. When I tried to reboot it no longer
ask me for my passphrase.
It showed only this:
open(hd0a:/etc/boot.conf): Invalid argument
boot>
cannot open hd0a:/etc/random.seed: Invalid argument
booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
failed(22). will try /bsd
After searching online I discovered this: boot sr0a:/bsd. Now it asks for
my Passphrase and it starts booting but then it hangs
softraid0 at root
scsibus2 at softraid0: 256 targets
panic: root device (3312a...) not found
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
* 00 0 0x1 0x2000 0kswapper
panic(ff81dff) at panic+0x12a
setroot(80..) at setroot+0xdeb
disconf(1b21..) at diskconf+0x185
main(0,0,0,0,0,80..) at main+0x500
end trace frame: 0x0, count:10https://www.openbsd.org/ddb.html
describes the minimum info required inbug reports. Insufficient
info makes it difficult to find and fix bugs.
ddb{0}>
Using a usb drive with *FuguIta* I managed to do a fsck on all partitions
(some errors appeared, but I cleaned them).
I was even able to mount them and everything seems fine, I recovered what I
was working on, but I have no luck in booting. Again and again the above
error.
I am a little puzzled that there is no failsafe mechanism for commands like
bioctl or fdisk on the already mounted disk. For me the obvious think was
that the system complains when trying bioctl -d sd0.
Thank you for your help!
Re: OpenSMTPD is not sending e-mail.
On Tue, Jan 26, 2021 at 5:25 PM latincom wrote: > > Hello misc@ > > I can not believe that the solution has been to open port 25, Vultr rent > servers whit port 25 closed! > > Thanks so much to Stuart Henderson for the solution. Yes Vultr and many other VM providers block tcp port 25 by default, however most will open it up if you request it.
Re: auto-boot
On Tue, Jan 26, 2021 at 5:30 AM Stuart Longland wrote: > > On 25/1/21 11:40 pm, Bastien Durel wrote: > > Hello, > > > > Short-circuit pins 3-5 using my DB9 cable as Mihai Popescu said[1] > > worked. > > Alas, this setup prevent to plug-in the cable on the other side ^^ > > > > But this confirm there is an hardware problem. The issue is the input RCV line is floating which causes spurious characters, a properly designed circuit should not have this issue. You really should insert a high ohm valu resistor in the path between RCV and GND, this would allow you to build a serial cable that still functions.
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8 (SOLVED)
Hi all, I have exported "CC=/usr/bin/clang" in the shell and now Suricata compiles ok. Many thanks to all for your help. On 27/1/21, 14:45, "owner-m...@openbsd.org on behalf of Carlos Lopez" wrote: HI Stuart, Many thanks for your help. I have tried to compile using "--with-clang=/usr/bin/clang" flag but same error appears... On 27/1/21, 13:49, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2021-01-27, Carlos Lopez wrote: > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez > It is using the wrong compiler, OpenBSD/amd64 still installs the old version of gcc as /usr/bin/gcc and some software picks this up. I suggest modifying the port to suit your needs rather than building it standalone.
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
HI Stuart, Many thanks for your help. I have tried to compile using "--with-clang=/usr/bin/clang" flag but same error appears... On 27/1/21, 13:49, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2021-01-27, Carlos Lopez wrote: > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez > It is using the wrong compiler, OpenBSD/amd64 still installs the old version of gcc as /usr/bin/gcc and some software picks this up. I suggest modifying the port to suit your needs rather than building it standalone.
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
Thanks Gonzalo. Yes I would like to compile without rust support and with GeoIP support ... On 27/1/21, 13:49, "Gonzalo Rodriguez" wrote: I don’t remember now the version we have in 6.8 but are you compiling it for some reason instead of use the package? — gonzalo > On 27. Jan 2021, at 13:31, Carlos Lopez wrote: > > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
I don’t remember now the version we have in 6.8 but are you compiling it for some reason instead of use the package? — gonzalo > On 27. Jan 2021, at 13:31, Carlos Lopez wrote: > > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the > following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with > --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
On 2021-01-27, Carlos Lopez wrote: > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the > following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with > --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez > It is using the wrong compiler, OpenBSD/amd64 still installs the old version of gcc as /usr/bin/gcc and some software picks this up. I suggest modifying the port to suit your needs rather than building it standalone.
Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
Hi all, I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: hecking for strlcat... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok checking for c11 support... no checking for thread local storage gnu __thread support... no configure: error: "no thread local support available." Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. Regards, C. L. Martinez
OpenBSD (memory management) performance issues
Hi,
We are working on an appliance like product that is based on OpenBSD.
Recently we found out that our performance critical C++ program is
~2.5 times slower on OpenBSD compared to Ubuntu 20.04.
The program basically just reads data from stdin, does some
transformation of the data, and returns the result on stdout, thus
the program does not perform any further I/O operations nor interacts
with other programs. We extensively use the C++ standard library string
class for manipulation of data.
We started searching for the reason, and eliminated I/O as a factor.
During some experiments we found out that one, perhaps not the only
one, factor is OpenBSD's memory management. To test this assumption we
wrote a simple program that allocates and frees memory in a loop.
Something like:
for (...) {
void *buffer = malloc(...);
...
free(buffer);
}
We compiled it on OpenBSD with clang
$ /usr/bin/c++ --version
OpenBSD clang version 10.0.1
Target: amd64-unknown-openbsd6.8
Thread model: posix
InstalledDir: /usr/bin
using options '-O3 -DNDEBUG -std=gnu++11' and ran it without memory
junking.
$ time MALLOC_OPTIONS=jj ./memory_allocs --cycles 123456789 --size 1024
real0m27.218s
user0m27.220s
sys 0m0.020s
We compiled the same program on Ubuntu 20.04 with g++
$ /usr/bin/c++ --version
c++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
using the same options '-O3 -DNDEBUG -std=gnu++11'
$ time ./memory_allocs --cycles 123456789 --size 1024
real0m1,920s
user0m1,915s
sys 0m0,004s
Both systems were tested in the same virtualized environment (VSphere),
thus we can assume the "hardware" is the same.
Given the virtual environment, the tests might not be scientifically
the best choice, but they serve the observation well enough. We
actually ruled out virtualization as a cause in other tests.
What other options are there we could try in order to speed the memory
management up?
Also are there any other known areas, for CPU bound processing, where
OpenBSD performs worse than other "common" platforms?
Cheers,
Marek
Re: iked(8) CREATE_CHILD_SA successful at initial connection time, fail at rekey interval
Hi, looks like a PFS problem. Here's where it fails: > Jan 26 18:48:30 strannik iked[41041]: spi=0x6184b254a8e8d175: > ikev2_log_proposal: ESP #1 DH=MODP_2048 At the moment, PFS groups must be enabled manually. Try this: ikev2 "home" passive esp inet \ from 10.0.10.0/24 to 10.0.1.0/24 \ from 10.0.10.0/24 to 10.0.4.0/24 \ from 10.0.10.0/24 to 10.0.7.0/24 \ local responder peer initiator \ childsa group modp2048 \ srcid "/CN=responder" dstid "/CN=initiator" - Tobias
Re: 6.8 and Procmail/Formail: anyone still using them?
aus...@computershop.ca (Austin Hook), 2021.01.26 (Tue) 18:43 (CET): > Wonder if anyone is still using Procmail/Formail under 6.8 for > presorting incoming mail before it hits one's main inbox. Regarding procmail beware of this: https://marc.info/?l=openbsd-ports&m=151256201621939 formail is not in the ports tree, afaict. I switched from procmail to fdm: Information for inst:fdm-2.0p0 Comment: fetch, filter and deliver mail Description: fdm is a simple, lightweight replacement for mail fetch, filter and delivery programs such as fetchmail and procmail. It can fetch using POP3 or IMAP (with SSL) or from stdin, and deliver to a pipe, file, maildir, mbox or SMTP server, based on regexps. Maintainer: Nicholas Marriott > Also wondering if folks send the remainimg mail, after filtering, to > /var/mail/*user*, or to ~/mbox or to ~mail/mbox. Any advantage to be had, > or any mere consensus, regardless of advantages? I use ~/Maildir Marcus
smtpd virtual table with only userparts
For an smtpd.conf containing this:
8<
table domains { mydomain.tld }
table virtuals file:/etc/mail/virtual
action "domain" maildir "/var/vmail/mydomain.tld/%{dest.user}" virtual
match from any for domain action "domain"
8<
The following virtual file works:
8<
bertalan.pe...@mydomain.tld b...@mydomain.tld
b...@mydomain.tld vmail
8<
That is, when I send mail to both and
, it is delivered to the
/var/vmail/mydomain.tld/bp99/.
After reading this[1], I tried to remove the domain parts from my
virtual table:
8<
bertalan.peter bp99
bp99vmail
8<
But this caused email sent to be delivered
to a /var/vmail/mydomain.tld/bertalan.peter/.
Is it possible to skip the domain part in a virtual table file?
That way I could also reuse the file with a different domain.
Thank you
Bertalan
[1]: https://undeadly.org/cgi?action=article&sid=20130130081741>,
--
Bertalan Z. Péter
PGP: FB9B 34FE 3500 3977 92AE 4809 935C 3BEB 44C1 0F89
signature.asc
Description: PGP signature
