deb/rpm packages

[natesales]

It would be great to include production builds for linux as deb/rpm packages. I'd be happy to open a PR for this with goreleaser if that works for the maintainers. (This could also address #19 for docker builds)

[job]

PRs are welcome!

[ties]

Especially for packaging! Since per distro packaging is best done by someone actually using that distro to make it more idiomatic.

[rfc1036]

FYI, stayrtr is currently available in Debian/testing and Ubuntu 22.04 LTS.
A backport to Debian/stable may appear depending on users demand.

[ichilton]

@rfc1036 Is it possible to get stayrtr in to bullseye-backports?

[rfc1036]

I can work on it soon, but can you make a new release since there are a lot of unreleased commits at this point?

[ties]

We need to do a release. I know rtrmon in head is solid, but do not use stayrtr itself

[rfc1036]

Again, I would be happy to package a new release if you could bless one...

[ties]

@job do you have a revision you know you have been stability running in production for a while? The easiest path forward may be to turn a known good version into a release.

I expect HEAD to be good, but I do not use the RTR part. HEAD of rtrmon is definitely good.

[job]

RSSF.nl is in the process of hiring a contractor to produce a blessed release. I think it'll be good if a Go expert is given ample time to take a good look at this app. Please be patient!

[rfc1036]

FYI, we are running out of time for getting a new stayrtr in the next Debian release.

[benjojo]

How long do we have?

[rfc1036]

I have to upload it before the FOSDEM week end, and if I will be that late then I have to get it right the first time or it will not migrate in time.

[benjojo]

I have tagged v0.4.0

I also cleaned up some of the packaging situation, the CI now outputs RPMs and DEBs, however I suspect debain will want to do it's own packaging of this software to comply with their standards for packaging golang projects

[rfc1036]

I have uploaded 0.4.0 to the Debian archive.

[ties]

Do we have a place where this can run in production as QA?

I wish this project had a better test harness. I had some ideas for end to end testing but never gave that priority. In general there is little testing available for RTR (and many/misbehaving clients)

[benjojo]

I've been testing what I've been writing against a little JunOS SRX110 and one of my bird2 routers.

I'm unsure how in general we can do reasonable end to end testing in a timely fashion, but I'll think about it

[ties]

Good to hear that - I think that is the level of end-to-end testing we reasonably do.

I would like it if there was a tool that could easily emulate a high number of connections, based on an independent implementation of the protocol. It's feasible but a lot of work. I want to look at using cloudflare/rpki-rtr-client at some point as a basis for such a client.

[benjojo]

I would like it if there was a tool that could easily emulate a high number of connections,

I assume you are saying this because your day-to-day usecase is a StayRTR with lots of client connections.

Can you give a ballpark on how many connections you are thinking?

[ties]

I would like it if there was a tool that could easily emulate a high number of connections,

I assume you are saying this because your day-to-day usecase is a StayRTR with lots of client connections.

Can you give a ballpark on how many connections you are thinking?

My day job (RIPE NCC) does not involve running an rtr daemon. However we do run rtrmon for end to end monitoring between CA systemen and what is visible for RPs.

I have seen a screenshot of a dashboard of a rtr server with ~500 clients. However I can imagine those parties would not like to comment in public about the size of their networks.

[benjojo]

deb's and rpm's are available, I'm gonna close this