Re: Sunday presentaion on OpenBSD
On Mon, Aug 30, 2021 at 01:33:43PM +0200, jeanfrancois wrote:
> Hello,
>
> I must have missed the time, wrong time zone.
>
> No record, only slides ?
The meeting was not recorded, unfortunately. However, the article ("Writeup")
has essentially the same text as what was said except a couple of questions
at the very end.
Slides: https://home.nuug.no/~peter/openbsd_moments/ (which also has a link to
the article
ihttps://bsdly.blogspot.com/2021/08/recent-and-not-so-recent-changes-in.html)
- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Applying scan_ffs output to disklabel?
On 8/30/21 7:53 AM, Danny Wilkins wrote: On August 29, 2021 11:06:03 PM EDT, gwes wrote: If there aren't sufficient backups I have a version of scan_ffs which works on FFS2. geoff steckel I feel like that'd be good to have in base in general now that ffs2 is default. Any reason the patch isn't in? It didn't get an OK. I believe the latest version is a minimal change to the current version. If there is interest from the core team I'll resubmit it and ask for criticism. geoff steckel
Re: Applying scan_ffs output to disklabel?
That might be helpful as sadly I do not have backups for this device. Could you share at your convenience? On Sun, Aug 29, 2021, at 11:06 PM, gwes wrote: > On 8/29/21 10:51 PM, Kenneth Gober wrote: > > On Sun, Aug 29, 2021 at 5:35 PM Jason Morris wrote: > > > >> I'm in the process of recovering my drive (fat fingered dd and blew away > >> the partitions). I've obtained the following output from scan_ffs but not > >> sure how to apply this to recreate the disklabel. Running disklabel -R with > >> this output doesn't seem to work. > >> > >> fuguita# scan_ffs -lv sd2c > >> block 128673234 id a86900, 1d53400 size 30225408 > >> block 150903347 id 8,0 size 76481934 > >> block 475612813 id 502b55c2,800e9b02 size 1130083924 > >> block 587802509 id 502b55c2,800e9b02 size 1130083924 > >> block 867995213 id 502b55c2,800e9b02 size 1130083924 > >> block 1338443597 id 502b55c2,800e9b02 size 1130083924 > >> block 1638543507 id abbbeaf9, b4ab0641 size 472173501 > >> scan_ffs:_read: Invalid argument > >> > > According to the man page, scan_ffs will work only on FFS file systems, not > > FFS2. Since FFS2 > > is now the default, presumably scan_ffs wasn't able to find any file > > systems. If it had found > > something, it would have output one or more lines looking something like > > these: > > > > X: 524224 64 4.2BSD 2048 16384 1 # / > > X: 4194304 524288 4.2BSD 2048 16384 1 # /usr > > X: 1048576 4718592 4.2BSD 2048 16384 1 # /usr/local > > > > There should be a backup of your disklabel in > > /var/backups/disklabel.sd2.current (or sd0, or sd1, > > etc. as appropriate depending on how things were configured previously). > > If you have backups, > > the easiest thing to do is look through those backups to find this file. > > If you don't have backups, > > here is an example of what one of these disklabel files might look like; > > you might be able to find > > it on your disk just by reading blocks until you find it (assuming it's not > > encrypted): > > > > # /dev/rsd0c: > > type: SCSI > > disk: SCSI disk > > label: DELL PERC H700 > > duid: 26daa7a4492ed6e9 > > flags: > > bytes/sector: 512 > > sectors/track: 63 > > tracks/cylinder: 255 > > sectors/cylinder: 16065 > > cylinders: 36404 > > total sectors: 584843264 > > boundstart: 100759680 > > boundend: 584830260 > > drivedata: 0 > > > > 16 partitions: > > #size offset fstype [fsize bsize cpg] > >a: 1028160100759680 4.2BSD 2048 16384 8000 # / > >b:131604480101787840swap# none > >c:5848432640 unused > >d: 4112640233392320 4.2BSD 2048 16384 12958 # /usr > >e: 2056320237504960 4.2BSD 2048 16384 12958 # > > /usr/local > >f: 1028160239561280 4.2BSD 2048 16384 8000 # /var > >g: 16450560240589440 4.2BSD 2048 16384 12958 # /tmp > >h: 411264025704 4.2BSD 2048 16384 12958 # /home > >i:64197 63 unknown > >j: 5121522064260NTFS > >k:197406720261152640 4.2BSD 2048 16384 12958 # > > /var/postgresql > > > > Note that a 'normal' installation of OpenBSD will typically have a much > > smaller boundstart > > value, like 64. The system I took this sample from has both Windows and > > OpenBSD on > > it so the layout is a bit unusual. > > > > -ken > If there aren't sufficient backups I have a version of scan_ffs which > works on FFS2. > geoff steckel >
Re: Applying scan_ffs output to disklabel?
On August 29, 2021 11:06:03 PM EDT, gwes wrote: >On 8/29/21 10:51 PM, Kenneth Gober wrote: >> On Sun, Aug 29, 2021 at 5:35 PM Jason Morris >wrote: >> >>> I'm in the process of recovering my drive (fat fingered dd and blew >away >>> the partitions). I've obtained the following output from scan_ffs >but not >>> sure how to apply this to recreate the disklabel. Running disklabel >-R with >>> this output doesn't seem to work. >>> >>> fuguita# scan_ffs -lv sd2c >>> block 128673234 id a86900, 1d53400 size 30225408 >>> block 150903347 id 8,0 size 76481934 >>> block 475612813 id 502b55c2,800e9b02 size 1130083924 >>> block 587802509 id 502b55c2,800e9b02 size 1130083924 >>> block 867995213 id 502b55c2,800e9b02 size 1130083924 >>> block 1338443597 id 502b55c2,800e9b02 size 1130083924 >>> block 1638543507 id abbbeaf9, b4ab0641 size 472173501 >>> scan_ffs:_read: Invalid argument >>> >> According to the man page, scan_ffs will work only on FFS file >systems, not >> FFS2. Since FFS2 >> is now the default, presumably scan_ffs wasn't able to find any file >> systems. If it had found >> something, it would have output one or more lines looking something >like >> these: >> >> X: 524224 64 4.2BSD 2048 16384 1 # / >> X: 4194304 524288 4.2BSD 2048 16384 1 # /usr >> X: 1048576 4718592 4.2BSD 2048 16384 1 # /usr/local >> >> There should be a backup of your disklabel in >> /var/backups/disklabel.sd2.current (or sd0, or sd1, >> etc. as appropriate depending on how things were configured >previously). >> If you have backups, >> the easiest thing to do is look through those backups to find this >file. >> If you don't have backups, >> here is an example of what one of these disklabel files might look >like; >> you might be able to find >> it on your disk just by reading blocks until you find it (assuming >it's not >> encrypted): >> >> # /dev/rsd0c: >> type: SCSI >> disk: SCSI disk >> label: DELL PERC H700 >> duid: 26daa7a4492ed6e9 >> flags: >> bytes/sector: 512 >> sectors/track: 63 >> tracks/cylinder: 255 >> sectors/cylinder: 16065 >> cylinders: 36404 >> total sectors: 584843264 >> boundstart: 100759680 >> boundend: 584830260 >> drivedata: 0 >> >> 16 partitions: >> #size offset fstype [fsize bsize cpg] >>a: 1028160100759680 4.2BSD 2048 16384 8000 # >/ >>b:131604480101787840swap# >none >>c:5848432640 unused >>d: 4112640233392320 4.2BSD 2048 16384 12958 # >/usr >>e: 2056320237504960 4.2BSD 2048 16384 12958 # >> /usr/local >>f: 1028160239561280 4.2BSD 2048 16384 8000 # >/var >>g: 16450560240589440 4.2BSD 2048 16384 12958 # >/tmp >>h: 411264025704 4.2BSD 2048 16384 12958 # >/home >>i:64197 63 unknown >>j: 5121522064260NTFS >>k:197406720261152640 4.2BSD 2048 16384 12958 # >> /var/postgresql >> >> Note that a 'normal' installation of OpenBSD will typically have a >much >> smaller boundstart >> value, like 64. The system I took this sample from has both Windows >and >> OpenBSD on >> it so the layout is a bit unusual. >> >> -ken >If there aren't sufficient backups I have a version of scan_ffs which >works on FFS2. > geoff steckel I feel like that'd be good to have in base in general now that ffs2 is default. Any reason the patch isn't in? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Sunday presentaion on OpenBSD
Hello, I must have missed the time, wrong time zone. No record, only slides ? Thanks & regards JeanFrançois Le 30/08/2021 à 05:33, Jonathan Drews a écrit : On Sun, Aug 29, 2021 at 11:52:57PM +0100, Chris Narkiewicz wrote: On Sat, Aug 21, 2021 at 07:12:41PM -0600, Jonathan Drews wrote: This Sunday Peter Hansteen will give a presentaion on OpenBSD: "Recent and not so recent changes in OpenBSD that make life better" Any recording available? I am afraid not. However peter has posted a writeup: The Slides https://home.nuug.no/~peter/openbsd_moments/#1 The Writeup https://bsdly.blogspot.com/2021/08/recent-and-not-so-recent-changes-in.html
Re: (Feedback needed) openbsd and ulimits.
Vladimir Nikishkin writes: > Hello, everyone. > > I found this problem when trying to write some go on OpenBSD: > > https://github.com/google/starlark-go/issues/382 > > OpenBSD enforces ulimits on virtual space, whereas many operating > systems do not. `starlark`, as, in fact, many other pieces of software, > casually allocate "all virtual space in 32 bits", because presumably > that does not hurt on other operating systems. Hence, software using > starlark compiles, but does not run. > > What would be the best approach to make it work on OpenBSD? > > I am not an expert on POSIX memory management in any sense of the word, > so please, those who are, comment on that issue. Allocating memory for all representable int32 values seems dumb IMO, but I've never heard of starlark and they may have their reason. Regarding the issue, you wrote: > I think the limit for ordinary users is 1052672 and something about > 1552672 for the staff login class, and it is not possible to go above > that. It's possible (albeit probably not suggest unless you know what you do) to bump that number, but you need to mess with login class and edit /etc/login.conf, see login.conf(5), which may or may not be advisable for users of starlark (again, I've never heard before of it so I don't know in what circumstances it's used) Anyway, disabling the "optimisation" on OpenBSD as the guy from google suggested seems the most sensible choice IMHO. My two cents, Omar Polo
Re: Does anyone have experience with OpenBSD on SiFive Unmatched?
> > In this moment on -current, how well does the SiFive Unmatched RISCV64 > > board work? > > > > E.g. multiple core support, PCIe. > > Works fine. > > > E.g. multiple core support, PCIe. > > Works, and works. > The "serial cable" can in fact be just a USB-A to Micro-USB cable > with the A end plugged into a USB port on a laptop or PC. > > The micro-SD card must be present to boot OpenBSD (so maybe make > a backup copy of it?). IDK exactly what files it needs. Maybe > somebody will figure out how the boot stuff can be flashed into > flash mem on the motherboard without bricking their board. > > And bear in mind the Unmatched is meant to be a developr machine not > > powerhouse; it lopes along nicely at 1.2GHz with 4 cores. If the RISC-V > people are right, there will be faster, bigger machines "real soon > now", in case you need breath-holding practice. Hi Mike and Ian, Wow. Thank you for letting me know. If the ISA even has it, two questions on the topic of virtualization: Is the riscv64 architecture designed in such a way that riscv64 OpenBSD should work out of the box as guest under a virtualizer, if-when one exists? And off-topic here, does any VM host exist for riscv64? Without or with passthrough of PCI/cad/etc. I see this KVM fork but not sure exactly in what environment/ distribution/setup it works e.g. does it support Unmatched, not even clear if virtualization is really in the riscv64 ISA spec: https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-QEMU https://lwn.net/Articles/856685/ https://lists.riscv.org/g/tech-privileged/topic/risc_v_h_extension_freeze/80346318?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80346318 https://lwn.net/ml/linux-kernel/CAAhSdy0F7gisk=fzxn7jmqflvb3456wunwvxhkrnvnuwtrh...@mail.gmail.com/ Perhaps this q is too early for riscv64 and to be revisited later. Best regards, Joseph (Related: https://news.ycombinator.com/item?id=27592187 38bit vmem upped to 48 https://www.sifive.com/cores/performance-p550 https://www.anandtech.com/show/16780/intel-to-create-riscv-development-platform-with-sifive-p550-cores-on-7nm-in-2022)
Re: Accessing LAN behind gateway from Road Warrior on wg(4) based tunnel
On 2021-08-29, Erling Westenvik wrote: > On Fri, Aug 27, 2021 at 07:36:21PM -, Stuart Henderson wrote: >> >> Make sure you have set wgaip to allow traffic from the machines on the >> subnet on the other side of the tunnel. > > That was it. Thank you so much. Not directly intuitive to me that > "access" to a remote subnet must be specified on the connecting client, > but I think I understand the mechanisms a little better now. > > I can now access my home/office LAN which was my primary goal but I just > found out that traffic to everything else leaves egress untunneled. > However - trying something like: > > route change default 10.0.0.1 > > leaves the laptop dead in the water. Again a routing problem of some > kind I guess. Any hints on where to start digging? Changing the default route means that wg won't be able to reach the endpoint because the route to it is over the wg interface itself. If you want to tunnel all traffic, the easiest way is: - set your physical interface in a different routing domain, e.g. add "rdomain 2" to hostname.em0 - set wg to use the route table associated with that routing domain when sending the encapsulated packets, e.g. add "wgrtable 2" to the wg interface itself. - set your physical interface in a different routing domain, e.g. add "rdomain 2" to hostname.em0 - set wg to use the route table assocoated with that routing domain when sending the encapsulated packets, e.g. add "wgrtable 2" to hostname.wg0 - on the machine you're connecting wg to, unless you use externally routable IPs directly on the wg interface, you'll probably want something like "match out on em0 received-on wg0 nat-to (em0)" - and because now you'll be receiving traffic from anywhere over the wg interface you'll need wgaip 0.0.0.0/0 I think that covers everything but if not then tcpdump on various interfaces and both wg endpoints to figure out where packets are getting to, and that they have the expected address. -- Please keep replies on the mailing list.
