Hi,
Here's the summary of the IRC meeting.
---
COMMUNITY MEETING
Place: #openvpn-meeting on libera.chat
Date: Wed 6th July 2022
Time: 10:30 CEST (9:30 UTC)
Planned meeting topics for this meeting were here:
<https://community.openvpn.net/openvpn/wiki/Topics-2022-07-06>
Your local meeting time is easy to check from services such as
<http://www.timeanddate.com/worldclock>
SUMMARY
cron2, dazo, mattock, MaxF and ordex participated in this meeting.
---
Talked about OpenVPN 2.6.
The DCO patchset from from ordex was split it into smaller chunks. That
has paid off by making review easier and thus helping getting it merged
piece by piece.
The --ifconfig-noexec patch from MaxF is pending review by cron2.
---
Talked about the hackathon. MaxF should know next week if Fox-IT is ok
with hosting the hackathon or not. Lev's queries to F-Secure have
progressed, but there's no answer yet.
---
Mattock will be technically on vacation starting next Monday, but he'll
probably be working a few days to get the community services migration
in a good state, so that he can relax better.
---
Talked about --mktun. It is a linux-only feature to use openvpn as a
vehicle to create persistent tun/tap devices (... that can then be added
to bridge groups, even while openvpn is not running, etc.).
Part of its implementation is rather complex, and its functionality can
be replaced with an "ip tuntap" command on Linux on modern Linux distros.
Agreed to make --mktun a no-op with a warning on OpenVPN 2.6, then rip
it out in OpenVPN 2.7.
---
Talked about new Patchwork instance. Decided to try to migrate the
database from the old Patchwork instance. If that fails, we can resend
patches that are relevant to the new Patchwork, thus loosing a bit of
history in the process. Mattock will work on the database migration.
---
Talked about Trac. Mattock is making inquiries that will help determine
if self-hosting Trac (or something else) is really a management
requirement nowadays.
One migration option is codeberg.org, which is a SaaS service provided
by a non-profit foundation and that runs on top of Gitea open source
project. If self-hosting is a thing using self-hosted Gitea.
--
Full chatlog attached
(11:28:20) mattock: hello
(11:28:34) cron2__: early bird
(11:28:41) cron2__: :-)
(11:28:54) mattock: not that early
(11:28:56) mattock: :)
(11:29:01) cron2__: 2 minutes early
(11:30:37) MaxF [~m...@cust-95-128-91-242.breedbanddelft.nl] è entrato nella
stanza.
(11:30:53) cron2__: ooh, Hackathon
(11:31:13) cron2__: updated agenda :)
(11:33:04) d12fk: hi
(11:33:08) MaxF: hi
(11:34:30) ordex: hi!
(11:34:34) cron2__: ohi ;)
(11:35:00) mattock: sync up?
(11:35:16) ordex: yap
(11:35:27) cron2__: so, 2.5 -> nothing new from my end
(11:36:52) ordex: for 2.6 I got interesting rewviews for the DCO patches
(11:37:05) ordex: some will have to be resent (working on them) and some got
ACK'd
(11:37:17) cron2__: I like the activity that the "split patch into smaller
hunks" has caused
(11:37:22) ordex: so ideally the ACK'd once could be piped for final check&merge
(11:37:29) cron2__: so the plan worked (and thanks for your work)
(11:37:30) ordex: cron2__: +1 it worked pretty well
(11:37:41) ordex: although it was a bit painful :D but it's paying back
(11:37:52) ordex: (I also found issues while splitting, so all the better)
(11:37:55) cron2__: ordex: yes, I'll go through them one by one and if it has
an ACK, I'll apply when that patch is due (or when it can be applied
independently)
(11:38:20) ordex: yap yap, I think 2 or 3 can go in without waiting
(11:38:23) ordex: thanks
(11:38:44) becm [~b...@55d46585.access.ecotel.net] è entrato nella stanza.
(11:39:21) cron2__: this week, I won't get anything done, though - after this
meeting, I'll be busy with paid work until end of business day, and then 4 days
sandboarding trip with $kid - so, lots of real sand and friction, not much
virtual ;-)
(11:39:44) cron2__: I do read IRC and reply to mail, but focused testing is
very unlikely to happen
(11:40:12) cron2__: mattock: as a side note, can you find plaisthos and dazo on
internal chat?
(11:40:21) mattock: yes
(11:40:24) mattock: I'll poke them
(11:40:27) cron2__: I really want their opinion on --mktun
(11:40:55) mattock: done
(11:42:00) cron2__: anything else on 2.6?
(11:42:56) djpig [~flicht...@lovelace.lichtenheld.com] è entrato nella stanza.
(11:43:06) cron2__: hi :)
(11:43:09) MaxF: I've still got the --ifconfig-noexec patch
(11:43:21) ordex: yap, on my list to review again
(11:43:30) cron2__: MaxF: I think the plan is to get it in after 05 v14
(11:43:32) ordex: --mktun got me busy for the past few days
(11:43:40) ordex: yeah
(11:43:43) cron2__: so we need to make 05 go to v14 first ;-)
(11:43:46) ordex: :D
(11:44:34) cron2__: (and then we need to decide if we want this in 2.5, because
it's a bugfix - but the 2.5 patch would then look like one of the older
versions without DCO getting in the way)
(11:44:55) cron2__: I'm fine with including it, it is just more complex than
"just git cherry-pick"
(11:45:17) ordex: well, nobody really complained about this issue, no? it could
be considered as an improved behaviour in the new version
(11:45:32) ordex: although it's truly a fix
(11:46:02) MaxF: I complained, but I have a bunch of custom patches anyway, so
one more doesn't matter
(11:46:27) cron2__: we had one bug report, so that makes it a bug ;-)
(11:46:49) ordex: agreed
(11:48:25) ***dazo is here
(11:48:29) cron2__: so, anyway, this is for next week or so to decide. first,
05 v14 and then ifconfig-noexec v07 or so :-)
(11:48:32) mattock: welcome dazo!
(11:48:42) cron2__: so, Hackathon now?
(11:50:55) ordex: yeah
(11:52:14) dazo: MaxF: anything clarified on your end?
(11:52:19) MaxF: no news from me. Next week I should have an answer. At least
they promised that last week
(11:56:02) cron2__: okay... anything else on Hackathon?
(11:56:06) ordex: oky
(11:56:09) cron2__: (where is lev__ anyway, and plaisthos?)
(11:56:15) mattock: vacation probably?
(11:56:30) mattock: I know lev asked F-Secure in Helsinki if they'd be open to
hosting the hackathon
(11:56:42) mattock: he got an answer from "somebody" who promised to ask
"somebody more relevant"
(11:56:54) mattock: but afaik no response from the "more relevant" person yet
(11:56:57) cron2__: "some intereting news" ;-)
(11:57:37) cron2__: ok, so, --mtun/--rmtun now?
(11:57:38) mattock: while talking about vacations, I'll be on vacation starting
next week, though I will probably spend a few days trying to wrap up the
community services migration, so that I can relax better on my vacation
(11:57:43) mattock: cron2: +1
(11:58:20) dazo: cron2__: On --mktun and --rmtun .... I do think this makes
sense to kick it out these days with a major upgrade. Perhaps make OpenVPN
give a template response what to run instead for one major release? I would
expect most to be capable of running 'ip' or 'tunctl'
(11:58:24) cron2__: summary of --mktun -> this is a linux-only feature to use
openvpn as a vehicle to create persistent tun/tap devices (... that can then be
added to bridge groups, even while openvpn is not running, etc.)
(11:58:38) cron2__: that is the suggestion, yes
(11:58:43) cron2__: "openvpn --mktun --dev tun4"
(11:59:06) cron2__: "no longer supported. please run 'ip tuntap add mode tun
name tun4' instead"
(11:59:13) dazo: if it's Linux only .... I don't have strong feelings for keep
it in, especially if it complicates our code needlessly
(11:59:22) dazo: yeah, exactly that
(11:59:47) cron2__: the tuncfg() bit is fairly trivial, but it passes "keep
this around!" down to open_tun(), and THAT is a swamp hole
(12:00:34) ordex: yap
(12:00:38) dazo: 'ip' should be a safebet these days across basically all
(major) Linux distros .... It seems RHEL-8 has no tunctl longer (which was
needed when iproute2 was unavail)
(12:00:48) ordex: since there is an alternative (ip tuntap) I'd rather point
people to use that one
(12:00:54) dazo: +1
(12:01:00) cron2__: I'd keep the stub in "do_persist_tuntap()" (init.c) around
for 2.6, to make it print "the real command line to use now"
(12:01:06) cron2__: and rip it out completely in 2.7
(12:01:15) ordex: so we make --mktun no-op already in 2.6, right?
(12:01:20) dazo: that's a good path forward
(12:01:31) cron2__: "no-op with a good message what to use instead"
(12:01:34) ordex: no-op -> print message only and do nothing
(12:01:36) ordex: yeah
(12:01:37) cron2__: yes
(12:01:40) ordex: okok
(12:02:47) mattock: next topic?
(12:02:55) cron2__: mattock: not yet
(12:03:00) mattock: I shall wait then :D
(12:03:56) cron2__: ordex: does it make a difference for your work on 05 if we
rip out mktun first or afterwards? I have not enough insight in open_tun(),
open_tun_generic() and the current version of 05
(12:05:25) ordex: cron2__: some difference
(12:05:31) ordex: but it's not too much
(12:05:38) cron2__: so what would you prefer we do?
(12:05:51) ordex: we can rip it out later
(12:05:58) ordex: let's focus on getting dco as is first
(12:06:03) cron2__: ok, recorded
(12:06:21) ordex: kk
(12:07:09) ordex: I am basically adding one "if" with setting disable_dco =
true. we can easily remove that along with the mktun code later
(12:07:31) ordex: next topic ?
(12:07:59) cron2__: I've send a HEADS UP mail to the lists, to give people an
advance warning and ask for feedback on using "ip tuntap" instead
(12:08:05) cron2__: next topic, now mattock can charge ahead
(12:08:44) cron2__: patchwork
(12:08:46) ordex: ah thanks for the mail
(12:10:43) mattock: yes
(12:10:51) mattock: so, new patchwork is waiting to be moved to production
(12:10:59) mattock: for that we need ordex magic to resend relevant patches
(12:11:04) mattock: and a DNS change
(12:11:14) mattock: then some fixes to grant people the permissions to
patchwork they need
(12:11:29) mattock: so the question I guess is "when do we do it?"
(12:11:31) cron2__: can we move over the existing patch database with patch
numbers etc?
(12:11:42) cron2__: I am not so happy with losing history if we can avoid it
(12:11:48) ordex: basically we need to reforward *all* patches? what about the
status of already processed ones?
(12:11:49) mattock: well, that _might_ be doable, need to check the
documentation
(12:12:00) mattock: I can check the database migration route first
(12:12:01) ordex: (and patch numbers, yeah)
(12:12:09) ordex: migrating would definitely be most helpful
(12:12:11) cron2__: ordex: if we can't keep the history, we'd need to re-send
everything that is open
(12:12:17) mattock: unless the schema has changed it should be fairly easy to do
(12:12:21) ordex: and forget about things that were closed..ok
(12:12:37) ordex: mattock: if the schema has changed, maybe there is an upgrade
script?
(12:12:39) cron2__: being able to migrate the data would be really nice
(12:12:41) mattock: there should be
(12:12:44) mattock: yes
(12:12:57) mattock: so I'll check that out and in the worst case we resend
(12:13:07) dazo: we should try to see if we can preserve the history, otherwise
we're loosing a bit more than just the current state
(12:13:16) cron2__: (dazo's merge-and-push scripts nowaday reference patchwork
IDs, but that is only one patch and we could find it by message ID if
unavoidable)
(12:13:45) dazo: yeah, Message-ID is our primary index key, that's true
(12:13:55) cron2__: yeah... it started out as a "keep eye on TODOs" list, but
has become really useful to look up stuff
(12:14:27) mattock: I need to leave soon, so a quick update on Trac
(12:14:29) cron2__: and discussion threads on a specific patch
(12:14:39) cron2__: yes, trac
(12:14:56) ordex: btw patchwork by design does not add patchwork metadata to
patches to avoid issues like this. but we intentionally do now? :D
(12:15:02) mattock: I created a ticket to the openvpn inc's web development
lead, asking how many requests to https://openvpn.net originate from
https://community.openvpn.net
(12:15:03) vpnHelper: Title: Business VPN | Next-Gen VPN | OpenVPN (at
openvpn.net)
(12:15:31) mattock: basically to determine if the original motivation of
self-hosting (=linking back to "Commercial Products") is still valid/useful
(12:15:43) mattock: no response yesterday, may have to push her
(12:16:29) ordex: (mattock: FTR:
https://patchwork.readthedocs.io/en/latest/deployment/upgrading/#upgrade-your-database)
(12:16:30) vpnHelper: Title: Upgrading — Patchwork 3.1.0.alpha.0 documentation
(at patchwork.readthedocs.io)
(12:16:31) cron2__: I am always leaning towards self-hosted because I trust no
"yeah, come to us, it's free!" corp offerings
(12:16:57) cron2__: but that is me...
(12:17:07) cron2__: (and no, github has no proper v6 support either :-((( )
(12:17:17) cron2__: gitlab has, for some parts
(12:18:02) dazo: I've started testing out codeberg ... which is a Berlin based
non-profit org building a service around gitea ... and it looks a lot like
github in many ways, just not as "graphically polished"
(12:18:45) mattock: ticket created about patchwork db migration
(12:18:45) dazo: I did a complete migration from GH to codeberg for
openvpn3-linux .... https://codeberg.org/OpenVPN/openvpn3-linux
(12:18:47) vpnHelper: Title: OpenVPN/openvpn3-linux: OpenVPN 3 Linux - Next
generation OpenVPN for Linux - openvpn3-linux - Codeberg.org (at codeberg.org)
(12:19:15) cron2__: as far as "user interface" goes, trac does the job for me -
I'm fine with simple
(12:19:20) mattock: a SaaS that is not evil?
(12:19:31) mattock: this codeberg.org thing
(12:19:39) dazo: yes
(12:19:42) mattock: ok
(12:19:48) mattock: I'm fine with whatever tbh
(12:19:53) ordex: question is: will this stick around longe nough?
(12:19:57) ordex: *long enough
(12:19:58) dazo: It's also recommended by SFC too
(12:20:11) mattock: if they have funding they will probably stick around?
(12:20:20) mattock: (I have 5 minutes left, then lunch appointment)
(12:20:25) ordex: or in 4/5 years we'll have to migrate again because $start-up
lost investing round of they got acquired by $company doing $other stuff
(12:20:35) ordex: *or
(12:20:39) mattock: possible
(12:20:40) dazo: it's getting a lot of traction with several thousands users
and projects .... and codeberg is now funding one fulltime gitea developer
(12:20:41) mattock: but that's fine
(12:21:04) cron2__: dazo: like, sf did, and github did, before it was acquired
and became evil...
(12:21:32) dazo: what is attractive here is that it's a non-profit org ...
contrary to sfnet and GH
(12:21:33) mattock: if codeberg has a reasonable import and export API then I
think it'd be ok
(12:21:34) ordex: hm it's not a company though
(12:21:39) ordex: it's a non-profit association
(12:21:41) cron2__: so... if we can make trac behave, my preferrence would be
"keep trac, keep it self hosted". But I'm not insisting on it.
(12:21:44) ordex: funded by donatons
(12:22:34) ordex: we could have corp join as supporting member :)
(12:22:36) mattock: we don't know if trac will behave until I have invented a
considerable amount of time on it (make it near-production-capable)
(12:22:51) dazo: ordex: my thought as well
(12:23:03) mattock: due to plugins
(12:23:27) cron2__: what plugins do we use?
(12:23:28) mattock: anyways, could somebody (that is, dazo probably) check the
codeberg import/export apis?
(12:23:31) mattock: cron2: lots
(12:23:44) mattock: cron2: some may not be necessary, but any plugin that does
not support python 3 will not work
(12:23:58) mattock: anyhow, I'll let you continue this discussion, I have to
leave now
(12:24:00) cron2__: this is why I'm asking - I'm only aware of the spam
filtering
(12:24:12) mattock: well that is the most important plugin
(12:24:27) dazo: mattock: https://codeberg.org/OpenVPN/openvpn3-linux ... that
was using the GH import .... I'll check export possibilities
(12:24:28) vpnHelper: Title: OpenVPN/openvpn3-linux: OpenVPN 3 Linux - Next
generation OpenVPN for Linux - openvpn3-linux - Codeberg.org (at codeberg.org)
(12:24:32) mattock: there are some navbar things and some other spam prevention
plugins
(12:24:40) mattock: the bayesian filter is the main spam filter plugin
(12:24:49) mattock: dazo: thanks!
(12:24:51) dazo: You can also tie your Codeberg account with GH and GitLab
logins
(12:24:52) ordex: gitea comes with APIs, so we can definitely do something,
even if they do not provide exactly what we need
(12:25:03) dazo: yeah
(12:25:21) mattock: -> lunch, will finish the summary after
(12:25:43) ordex: thanks
(12:25:48) cron2__: thanks indeed
(12:26:01) ***cron2__ has 5 minutes before the next meeting, so, off, coffee...
(12:26:04) ordex: alternatively, we can also just use redmine for project
tracking :-)
(12:26:09) ordex: I guess we are done with the meeting anyway
(12:26:52) dazo: if selfhosted is a requirement ... it seems easy enough to
spin up a Docker based gitea host ....
https://docs.gitea.io/en-us/install-with-docker-rootless/
(12:26:53) vpnHelper: Title: Installation with Docker (rootless) - Docs (at
docs.gitea.io)
(12:27:00) d12fk: bye then
(12:27:00) cron2__: not sure we need extra tools to track "our progress is
slower than planned" :-)
(12:27:04) cron2__: anyway
(12:27:06) cron2__: bye!
(12:28:34) dazo: hehe
(12:28:37) dazo: c'ya!
(12:28:59) dazo: mattock: Their APIs are at least comprehensive enough ...
https://try.gitea.io/api/swagger
(12:29:00) vpnHelper: Title: Gitea API (at try.gitea.io)
(12:37:39) dazo: mattock: a gitea dump/restore command line tool was merged 1.5
year ago https://github.com/go-gitea/gitea/pull/12244 ... you can run it
locally to get a local export of the repos, which you can then import to a
local gitea instance. In addition, there is the webUI import from a running
instance as well
(12:38:20) dazo: (kick off your own local gitea instance, run the import via
the webUI)
(12:39:53) dazo: combine that with the APIs .... it's hard to see how this
would be a lock-in.
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
