Re: Reference/Citation Manager -- Zotero or JabRef? (+ compilation of Zotero?)
"Stephan, Corey J" writes: What are academics and others who require citation management using in OpenBSD nowadays? i'm not an academic myself - merely engaged with academia - but i'd be interested to know the extent to which people are making use of refer(1). i've only started working in the roff ecosystem in recent years, having spent more time in the LaTeX world, and i've been increasingly appreciating it. Alexis.
Re: openbsd on nanopi R5C?
> On Apr 3, 2023, at 1:39 PM, Harald Dunkel wrote: > > Hi folks, > > has anybody succeeded in running OpenBSD on the Nanopi R5C? > https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5C > I have one. I spent 5 minutes and it didn’t jump up and come alive… haven’t tried very seriously yet.
openbsd on nanopi R5C?
Hi folks, has anybody succeeded in running OpenBSD on the Nanopi R5C? https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R5C I haven't bought the hardware yet. The R5S is in OpenBSD's supported hardware list on ARM. Regards Harri
Re: rdomains finally working!!
On 4/3/23 11:25, Claudio Jeker wrote:
On Mon, Apr 03, 2023 at 10:53:26AM +0100, Kaya Saman wrote:
Hey guys,
...
Taking an excerpt from the website I was following:
https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/
Citing:
Creating a loopback interface in rdomain 2 so that Host 1 can talk to Host 2
would look like:
ifconfig lo2 rdomain 2 127.0.0.1
route -T 2 add 192.168.1/24 127.0.0.1
Since lo2 is created inside rdomain 2, the IP address assigned to it doesn't
conflict with lo0 in rdomain 0.
Sure I can see traffic inside one of the loopbacks and tcpdump does claim
"pass out" but then nothing else happens. The other loopback interfaces have
no traffic in them and the destination network has no traffic either.
This is very much expected since you probably did not carefully read the
cited website.
You need a special pf.conf setup to make that work. As one caveat
mentioned in the article is that the default pf.conf rulesets skips lo(4)
interfaces and so the traffic will just be dropped (since there is no
state lookup and so no way to bounce the reverse traffic back into the
other rdomain).
In general I would suggest use pair(4) to route traffic between rdomains.
Doing it in pf(4) gives you more control but it requires careful handling
of the rulesets (as you noticed).
Hi Claudio,
thanks for the response and advice on pair (4), I will definitely read it.
Maybe you are correct in that I didn't carefully read or perhaps I
confused things badly I have a mixture of ASD and most likely ADHD
and when the panic kicks in things become difficult including
communication and understanding.
I wish I had a spare system to test things properly and understand
better, unfortunately I am having to adapt a live production system and
with a large number of lines in the PF rule set is not easy.
The caveat you mention about skipping lo (4) I disabled (I think?) as
per changing the 'set skip' to this:
#set skip on { lo, enc0 }
set skip on { enc0 }
so the loopback should be active in PF, further down in my config I have
a clause like this too:
#Allow Internal Communications
pass in on lo0
pass out on lo0
pass in on lo2
pass out on lo2
pass in on lo3
pass out on lo3
Maybe due to my existing PF things might not work properly in anycase, I
just wish I knew more about what I was doing to really have a handle on
the situation.
I'm still eager to contribute with a write up if you are interested but
due to my "circumstances" I maybe the only one with these issues :-(
so maybe writing things up in my case maybe useless and will probably
not be understood by anyone in general.
With PF the biggest handling issue is when mixing and matching using the
'quick' keyword as things get handled differently. Both the websites I
cited do *not* contain the 'quick' keyword at all. My local pf ruleset
contains many "pass in quick" or "block in quick" statements.
I would definitely be extremely happy to hear any more suggestions if
there are any but for now I will look at studying "pair (4)".
Thank you so much for chiming in! I really appreciate it :-D
Best regards,
Kaya
OpenBSD Release Art Submissions
What is the art submission process for OpenBSD releases? My sister is an artist and she was thinking of creating something for 7.3, or some subsequent release. Thanks, --Bruce
Re: what tools exist to help a beginner debug a hung syscall?
Thank you very much for your reply, this is extremely high signal.
On Mon, Apr 03, 2023 at 10:15:00AM -, Stuart Henderson wrote:
> On 2023-04-01, Paul Tagliamonte wrote:
> > I've been trying to take a library[1] I use on my Linux boxen, and coax
> > it into working on OpenBSD[2], and have been able to get a compiled .so
> > that looks good, with the exception of the USB transport. Given the
>
> This is probably the most informative reply from the previous times the
> subject came up:
>
> https://marc.info/?l=openbsd-tech=159420462501384=2
>
> (I don't think anything changed in this area since then).
Exactly the same, in fact! Disapointing reply, but after having spent a
bit over a week tracing this down, it's a relief to my ego that it's not
something obvious. It's doubly frustrating since what I do see in
kernelspace looks to be initialized sensibly, it just sits in progress
and never completes until EINTR.
I'll have to track down that GSOC work, but I'm not super inclined to
put a -current kernel into use outside the lab bench. I fear I may be
the next breadcrumb when someone tries this again within the next 4
years.
> OpenBSD's USB stack, especially regarding direct device access from
> userland, definitely has some issues that don't exist on other systems.
> FWIW I'm tending to run such devices on single-purpose Linux boxes now.
Totally. I was trying to get to 100% feature parity between OpenBSD and
Linux for some code I spend my free time on. Given the better idea I now
have of the landscape, I'm now trying to balance how much I want 100%
feature parity against the three practical options in front of me;
namely:
1) writing enough of a shim in libusb or libuhd to make this work as-is
today (the only reason I think this is possible is because
unmodified upstream rtl-sdr and hackrf are making libusb async calls
and getting data on my OpenBSD system)
2) make the most minimal kernel change to get the userland code working
3) giving up entirely on libuhd on OpenBSD
I'll likely give #2 an ernest try this week, and then fall back on #3. I
don't think I'm going to be the one to crack this multi-decade TODO in
spare cycles between work on a spare cycles project.
> I don't have a kernel core handy to test but you can load a kernel into
> gdb (watch out for reorder_kernel; you will need to save the actual
> kernel that produced the core) and may be able to load the core (saved
> in /var/crash after booting following "boot crash") into gdb with
> 'target kvm $file'. Not sure if you will get better results from base
> or ports gdb ("egdb" binary) in this case; try the other if one doesn't
> work. Though I don't think it's very widely used so may have rotted.
> Generally I think either ddb or adding debug code seem more common,
> also dt(4) helps figure out some things.
This is very pointer rich, thank you very much. I'll give this a try to
see if I can refine the workflow a bit. It sounds like I'm not far off
from best practice, which is -- again -- a bit of a relief.
> Here or maybe tech@. Though this (libusb/direct device access from
> userland) is not an area in which anyone is particularly active.
full ack
Thanks sth@ for your reply, I very much appreciate it.
paultag
--
:wq
Re: rdomains finally working!!
On Mon, Apr 03, 2023 at 10:53:26AM +0100, Kaya Saman wrote: > Hey guys, > ... > Taking an excerpt from the website I was following: > > https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/ > > Citing: > > Creating a loopback interface in rdomain 2 so that Host 1 can talk to Host 2 > would look like: > > ifconfig lo2 rdomain 2 127.0.0.1 > route -T 2 add 192.168.1/24 127.0.0.1 > Since lo2 is created inside rdomain 2, the IP address assigned to it doesn't > conflict with lo0 in rdomain 0. > > > Sure I can see traffic inside one of the loopbacks and tcpdump does claim > "pass out" but then nothing else happens. The other loopback interfaces have > no traffic in them and the destination network has no traffic either. This is very much expected since you probably did not carefully read the cited website. You need a special pf.conf setup to make that work. As one caveat mentioned in the article is that the default pf.conf rulesets skips lo(4) interfaces and so the traffic will just be dropped (since there is no state lookup and so no way to bounce the reverse traffic back into the other rdomain). In general I would suggest use pair(4) to route traffic between rdomains. Doing it in pf(4) gives you more control but it requires careful handling of the rulesets (as you noticed). -- :wq Claudio
Re: Securing ttys
Indeed your answer to the question 2 suggests that you haven't slept enough like me this night, if you just checked how much detailed was my emails you could realize that I was coming from the man (the perfect one). Replies from awake ones are very welcome. NB: I did more, after a snap, I tries to convert the overwhelming three lines of your answer to the required two lines of ttys, result: uk, undefined kingdom. And this is just.. Question 2 :D Apr 3, 2023 11:47:00 Zé Loff : > The answer for question 2 can be easily found on man ttys. The fact > that you didn't find it strongly suggests you didn't even *try* to find > it.
Re: what tools exist to help a beginner debug a hung syscall?
On 2023-04-01, Paul Tagliamonte wrote:
> I've emailed a few lists, but so far everyone either looked the other
> way quickly[0], didn't know, or didn't have time to help me out (fair
> enough!)
I think it's mostly a mix of "don't know anything about it" and "know
some things but not enough to give a useful reply".
> I've been trying to take a library[1] I use on my Linux boxen, and coax
> it into working on OpenBSD[2], and have been able to get a compiled .so
> that looks good, with the exception of the USB transport. Given the
This is probably the most informative reply from the previous times the
subject came up:
https://marc.info/?l=openbsd-tech=159420462501384=2
(I don't think anything changed in this area since then).
> Either that or this is a common libusb 'gotcha' that everyone eventually
> finds and patches that presents itself on OpenBSD by always locking up.
OpenBSD's USB stack, especially regarding direct device access from
userland, definitely has some issues that don't exist on other systems.
FWIW I'm tending to run such devices on single-purpose Linux boxes now.
> Everything is using USB3/xhci. That's the only bus on the system, and
> this device communicates using USB3 in this case.
> I've been able to set up the serial console, and get 'ddb' working well,
> but I am having a hard time using it without poking myself on the sharp
> bits. Is there a good way to explore the wedged system that isn't using
> ddb off a serial line? Looks like 'ddb' can 'boot crash'; is there a
> good workflow documented there?
I don't have a kernel core handy to test but you can load a kernel into
gdb (watch out for reorder_kernel; you will need to save the actual
kernel that produced the core) and may be able to load the core (saved
in /var/crash after booting following "boot crash") into gdb with
'target kvm $file'. Not sure if you will get better results from base
or ports gdb ("egdb" binary) in this case; try the other if one doesn't
work. Though I don't think it's very widely used so may have rotted.
Generally I think either ddb or adding debug code seem more common,
also dt(4) helps figure out some things.
> 0) Is there a good place to have this conversation? I don't see
> topical "usb subsystem interest group" mailing list(s) where this
> may be less tedious to most of the readers. I tried ports@[7], but
> I don't think that list was right either. I feel like a nunsense
> posting on all these lists right now.
Here or maybe tech@. Though this (libusb/direct device access from
userland) is not an area in which anyone is particularly active.
rdomains finally working!!
Hey guys, I can't spend too much time right now in writing up what I have done right now as I'm just about to head out of town to a local nature reserve in order to clear my head, but basically things are working!! At this stage with such limited documentation on the topic I wonder if I should do some kind of a writeup of it to share my own experiences? Hopefully later in the week and I'll pop it up on my GDrive maybe it can be turned into part of the doc or faq or an example page on the OBSD website? What I can gloss over right now is that the setup is very sensitive with minute changes having drastic effects. To be honest I don't even know how or when things started working but I checked my laptop test machine and icmp packet responses were being received properly. Running tcpdump on pflog does lie sometimes. It will often suggest "block" when in fact the problem is routing. Another issue that I came across is that the loopback addresses don't inter-route. I don't know how to make that one work at all? Taking an excerpt from the website I was following: https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/ Citing: Creating a loopback interface in rdomain 2 so that Host 1 can talk to Host 2 would look like: ifconfig lo2 rdomain 2 127.0.0.1 route -T 2 add 192.168.1/24 127.0.0.1 Since lo2 is created inside rdomain 2, the IP address assigned to it doesn't conflict with lo0 in rdomain 0. Sure I can see traffic inside one of the loopbacks and tcpdump does claim "pass out" but then nothing else happens. The other loopback interfaces have no traffic in them and the destination network has no traffic either. Over the weekend having gotten completely fedup I decided to try to use one of the rdomains as a transit system and connected my Cisco 2801 BGP/IPSec/GRE test bed to the vlan in question and attempted to use it as a simple WAN Edge gateway. At first I managed to ping the interface of the Cisco, as I set OSPF up so that I didn't need to bother with static routes. As soon as I moved the rdomain of the vlan from 0 over to 3, everything stopped working and I couldn't find a way to use OSPF within two separate routing tables. The man page does have a setting for this in the config but there is no mention if you can use 2x instances between rdomains. After that I fought with static routes and of course the strange behavior kicked in where sending icmp packets between the Cisco and OpenBSD machines just wasn't working. I really didn't understand this at all as they are Next-Hop connected devices. No specific PF rule and a default route was set to be the interface of the Cisco routers internal IP address. I ended up moving the setup back to what I had originally with 3x rdomains and again I could not communicate between rdomain 2 and rdomain 3, though I did have communication to rdomain 0 from rdomain 2. Having done some more thinking about it and looking at the Cisco setup I decided to try creating an extra vlan in rdomain 3 with the intention of using it as a transit vlan. I already had success in pinging the internal IP address of the OpenBSD machine from domain 2 to domain 3, so I figured what the heck I'll give it a try. It did work but I still couldn't ping the public address. I then moved the test machine from rdomain 2 to rdomain 3 to see if that would help with internal communication between the machine and the public IP address. Oddly enough it did work and local traffic sent to rdomain 0 was still working too.. though I was still unable to get any response from public address. This is a bit of a black hole for me because I left the system for a while and came back to find that it actually started to work?? It isn't logical of course but I can't recall if I made changes in the meantime and simply wasn't aware of anything happening. After testing a bit and confirming that in fact things were working and I was *not* sending traffic over my existing PlusNET WAN link, I proceeded to migrate my OpenVPN tunnel across. This proved to be tricky as I kept running into dreaded "tcpdump -enipflog" "block in on tun0" issues in fact that turned out to be a routing problem instead of a PF issue. Currently this is working too but with some strange adjustments to PF. The current 'pass' per port rulesets don't seem to work even with the 'rtable (x)' clause added. What does seem to work however is a generic 'pass to rtable (x)' ruleset I'll probably need to study my rules further in order to try to understand the behavior here Anyway, am gona shoot over to the Warburg Nature Reserve now and continue with my photography to hopefully share more images with the BBOWT later. Oh and of course to try to get rid of my headache too ;-) Thanks to everyone for trying to help on a subject that contains very limited documentation and examples. Like I said hopefully if I can do
Re: Securing ttys
On Mon, Apr 03, 2023 at 06:11:25AM +0200, Daniele Bonini wrote: > > Hello, > > After the last patches, thanks gosh it is arrived the last > *trendy*, *new* as *much acclaimed* keystrokes attack.. So I turned from > the road to work this night -> to try to fix my ttys. > Indeed, I'm here asking your help to avoid ways to remain locked out or > to just not remain more dirty in this "pond", possibly. > > My constraints are the followings: > 1) I would like to avoid root password request on single-user shell >(that it permits me to solve risky quiz while troubleshooting the system in >bad conditions) > 2) I would like as less as possible active ttys for a dev workstation >and indeed I would like all ttys locally bound. > 3) I would like to disable - if possible - the CTRL + ALT + FN >keystrokes combinations to recall each single TTY > > Doing this I wonder a couple of more details: > a) what is the cleanest as safest syntax to not jump start getty on >the network (including the zero possibility to eventually trigger >it..) > b) where to specify correctly the flag "local" (eg. in console and >ttyC0 ?) > c) I can safely disable all CN apart C0 or you consider this move >hazardous in the optic to rescue the system or so forth? > > Thnks, appreciated! :D > > > -- Daniele Bonini > Sometimes it *really* looks like you use this mailing list as a search engine... The answer for question 2 can be easily found on man ttys. The fact that you didn't find it strongly suggests you didn't even *try* to find it. --
