search

vitlabuda / tundra-nat64

A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux
BSD 3-Clause "New" or "Revised" License
38 stars 4 forks source link

Getting tundra into Debian #1

Open DanielG opened 1 year ago

DanielG commented 1 year ago

Hi,

I'm working on packaging tundra in Debian. We currently already have Tayga and Jool but I've found both of these have various problems so perhaps tundra is better :)

Could you do me a favor and tag a release? Packaging packages without any tags is always a major hassle in Debian unfortunately.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041858 for packaging progress.

--Daniel

vitlabuda commented 1 year ago

Hi, I am glad that there is such genuine interest in my project, thanks a lot for that :-)

Now, what would be the ideal format of the tag so the packaging process is as hassle-free as possible? "5.0.1", "v5.0.1", or something else? Or does it not matter?

-- Vít

DanielG commented 1 year ago

Hi Vít,

Doesn't really matter. As long as they exists there's all sorts of regex knobs to get the format adjusted to what the Debian workflow likes.

Me personally, I usually go for something like v1.2.

If you feel like going above and beyond, what is encouraged in Debian in terms of release process is (gpg) signed releases. That is signed tarballs, not git-tags. Problem is on Github technically the downloaded tarball output isn't considered stable so you'd have to re-upload both the tarball and it's signature and attach it to a (manually created) "release" in addition to pushing the git tag. Probably too much hassle. I know I wouldn't bother without a script that does that for me.

Maybe git will get around to replacing sha1 with something better within our lifetimes! :)

--Daniel

vitlabuda commented 1 year ago

Hi, the tags have been created and pushed to this repository. :-)

-- Vít

DanielG commented 1 year ago

Excellent, as you can see from PR activity, I've been busy reviewing and packaging tundra :)

vitlabuda commented 1 year ago

Hi, I would like to sincerely thank you for all the work being done. I will be reviewing and merging your PRs in the coming days*, and also doing some work on Tundra myself, as the code clearly (#3) needs some maintenance (FYI, I will most probably be removing the 'print-config' mode of operation, as it is pretty much useless and hard to maintain, so expect a new version of the program).

* I'm currently in the process of moving to a new place, so I have less time than would be ideal. :-)

Thanks again, Vít

DanielG commented 1 year ago

Hi Vít,

removing print-config is fine with me, I don't think tundra's config is complex enough for it to be necessary.

I'm probably going to shoot more patches when I get around to deploying tundra in my test network, but we're not in a hurry I can just patch what we need locally in my Debian package so take it easy :~)

Thanks, --Daniel

zealousGnu commented 1 year ago

I'm also quite interested in this issue, since if there are debian packages, we'd use it for our cluster (since tayga is quite old and only supports single threads...). How is it coming along?

DanielG commented 1 year ago

After initial packaging and subsequent more thorough code review I'm not sure anymore tundra is suitable for deployment yet. I'm looking at developing some kernel patches to support SIIT/NAT64 instead.

Depending on how hard that turns out to be I might yet come back to it.

vitlabuda commented 4 months ago

Hi, well, it has certainly been more than a few days, but I did not expect that my university studies (and things related to them) which I started last year would cost me basically 100% of my free time, so unfortunately, work on my hobby open-source projects had to be postponed. Sorry about that, and looking back, I could have at least left a comment here about the situation.

I finally have some time now, so I have done some work on the project in case the NAT64/SIIT kernel patches would turn out not to be viable. I fixed the problems mentioned in #2, #3 and mostly in #4. I am also investigating what would be a good and maintainable approach for creating manpages for the program and also the configuration file - while using help2man, as was suggested, would solve the problem for the program, it would not do it for the configuration file. I will let you know if I come up with anything.

-- Vít

vitlabuda commented 3 months ago

Hi, I added manual pages for both the program and the configuration file. They mostly mirror the program's --help and the comments in the example configuration file, but the contents are not entirely indentical (notably, a description of the configuration file's format has been added to the corresponding manpage).

In the end, I decided not to use automatic tools (e.g. help2man, as was suggested) for creating the manpages to make them more complete and "pretty" (in adddition, there would be the problem with the non-existing manpage for the config file, as mentioned in my previous comment). While they need to be maintained manually, I don't think that it is a big issue at this point, because I consider the program to be more or less feature-complete (after all, what else would you want a stateless NAT64 translator to do), and potential bug fixes or similar changes most probably won't have an impact on the manual pages, which document user-facing interface of the program.

-- Vít