Questions on building VyOS image from docker build

General questions
1

I’ve successfully followed the instructions at Build VyOS — VyOS 1.4.x (sagitta) documentation and was able to compile the VyOS 1.2.0 ISO version (according to the instructions).

My question is: Is the version just specified by the command

./configure --architecture amd64
–build-by “your@email.tld”
–build-type release --version 1.2.0

Or is the version specified by the code (branch/tag) that is checked out and the above command just labels it?

I.E., I would like to build the latest stable released VyOS 1.2.X (which version is latest stable released version? It is unclear having read through the blogs and tickets), 1.2.1, 1.2.2? 1.2.3?

Did the above command tell it to build 1.2.0 or was the above command just labeling the whatever code is present to build with the 1.2.0 version number?

I.E., if I wanted to build latest 1.2.X (1.2.2?) would I just put 1.2.2 in the above command line or would I set the git repo to a certain tag and/or branch?

I looked through the git tag on the crux branch and didn’t see any tags for point releases 1.2.0, 1.2.1, 1.2.2, 1.2.3, so just wondering how to be sure I’m getting what I think I’m getting.

Thanks.

1 Like
2

Or is the version specified by the code (branch/tag) that is checked out and the above command just labels it?

This is correct. What you put in the configure line just designates what show version will display. You would still need to actually choose the actual version you wanted from git.

3

Thanks for that information, it was unclear from the documentation.

So that leaves the question: How to get a certain version?

I’ve looked at “git branch -a” and “git tag” and don’t see tags or branches for particular point releases.

Is it somewhere else other than the vyos-build repository?

4

Hi dws!

The iso is not built by the git repositories, but instead built from an the official debian and our own apt repository containing the most up-to-date packages available. Because of this for now there are no way to build an “old” release, and on each build you get the newest release also containing all the fixes for the next release.
And for the time being there are also no way to actually check the version of the packages used, this is because we don’t increment the version tag on each build of the package.

5

I had the same question as DWS. Why are versions not tagged on release? I think that this would be incredibly valuable.

Max.

6

I very much agree with max1e6.

The VyOS maintainers say that you can build the software.

This is true, but if you can’t build a certain version, then you are left with getting the same thing as the rolling release.

PLEASE add release tags. I really would rather not run a rolling release on my production network. I sometimes do run rolling release on test VMs.

The software is open-source. We ought to be able to build the same version as the point releases.

I have been using VyOS since it was Vyatta and really like it a lot, and thank the developers for keeping it alive, but it is beginning to have more and more impediments to usage and seems to be falling behind the times wrt to several needed features that cause me to have to run multiple routers to do what should be able to be done all on one router.

Please seriously consider adding the 1.2.0, 1.2.1, 1.2.2, 1.2.3, etc., release tags to the repo so we can rebuild the official releases.

Thanks.

2 Likes
7

I fully agree with you on using tagging on the repository to tag a certain release, and that is a work undergoing to allow us to automatically tag packages that way. the biggest issue with this is that we use the upstream debian repository, so rebuilding will always get the lates debian packages… that way you newer could rebuild the exact same iso. to allow for this we need to snapshot the debian repo at time of official iso build, and thats something we don’t intend to do.

One other issue is that the iso is not built from the git-code directly and are using a custom apt repo(http://dev.packages.vyos.net/repositories/), thats also makes it difficult to reuse the tag later on, and only on a source-only-build are you able to reuse the tag from git.

About the version you build, for now there are TWO versions available for build, and rolling is one of them. The other one is curx (aka. 1.2.x) the 1.2.x versions are based on crux and not on rolling, also LTS is crux and not rolling. When you build crux you get the newest packages from 1.2.x including the hotfixes that will become the next 1.2.x release. building a crux iso is more safe than building from rolling because the crux build will only get bugfixes and new features that are considered safe. buliding rolling on the other hand gives you a lot of new features, but also a lot of new bugs…

As of now i would encourage you to build an image out if the crux branch, that will give you the most stability, as this is the LTS release it is also quite safe to build from. And if you’re not satisfied with that please consider starting contributing to the project (that will give you access to the LTS) or subscribing to the support service (that will also give you access).

The vyos project is for now a community work, but as the userbase of the community was not contributing this action are taken to make the community give something back to the project.

8

I’m going to try to present this as politely as possible. I may fail. So, apologies.

This thread (so far) says:

For people to identify any one specific LTS git commit/hash per GA (i.e., numbered) release…

On the one hand, that’s fair. It’s not the task of VyOS Maintainers to become Debian Maintainers. Debian is a moving target too.

On the other hand, that’s a bit willful. Speaking as a long time Vyatta homelab aficionado, that approach, unfortunately, feels a lot like a small group of folks attempting to monetize GA Releases via obfuscation of the ISO source moment-in-time. It’s charging users to subscribe to a needle, by pretending that the whole haystack is necessary. The surrounding haystack is not necessary, and the needle isn’t worth $1500/yr (important note: any professionalized support is indeed worth $1500/yr, however - basically the RedHat business model).

I’m happy to compile LTS crux myself. I’m happy to make an ISO myself. I’m happy to “install image” onto a VMware VM myself. I’m happy to support myself. I may even contribute. But DWS is 100% correct: “if you can’t build a certain version, then you are left with getting the same thing as the rolling release.”

Making “stable” be unstable (a.k.a. “rolling”) feels intentional and a bit crafty.

2 Likes
9

what is the Build Commit ID of the official 1.2.4 release? am I right to assume that if a homebuilt ISO shows the same Build Commit ID that I’ve got the real deal then?

10

Hello!

How about you with @dws spend some time and make it happen?
you will do that in the right way, how it should be. And also document everything after

And we all will appreciate that a lot.

11

It was never possible to build an image exactly equivalent to say 1.1.8 or 1.0.3. Build reproducibility for an entire distro is a hard and largely unsolved problem.

From 1.2.4, we’ve started tagging all packages in fact. That should help with reproducibility somewhat. As more components are rewritten and moved to vyos-1x, it will become simpler.

if you can’t build a certain version, then you are left with getting the same thing as the rolling release

That’s a very black and white view. We never merge experimental changes from current without testing them first. There have been unfortunate incidents with broken Crux images, but they are treated as emergencies and fixed as soon as possible.

a small group of folks attempting to monetize GA Releases via obfuscation of the ISO source moment-in-time

We are doing best we can do now to put as little behind the paywall as we can . We could keep LTS branches private and only give the source to paying customers. We could put the build scripts behind the paywall like pfSense did. We could require vague contributor agreements that allow us to close the source, like Observium did. We could, like, not work on trying to make the build system easy to use for anyone outside the small group of people working on it.
We chose not to and hid just enough to ensure the project gets funding to stay afloat. We also chose not to have contributor agreements of any kind to ensure no “small group” can close and appropriate the source. I hope maybe some day someone will appreciate it.

Also, don’t forget that we give away free subscriptions to contributors in the broadest sense of that word.

In short, we are by no means against build reproducibility and lack of it is not an evil business plan. It’s just not there yet because there are far more immediate problems to solve, like unmaintainable bits of legacy code inherited from Vyatta that require a complete rewrite to add even a small feature. If you want to work on build reproducibility, do it, make pull requests, and we’ll merge them.

1 Like
12

Hmmm. My tiny brain is having a hard time reconciling two things. On the one hand, I have enormous gratitude and respect for the 20 years of community effort by so many smart people, including the current VyOS Maintainers. Thank you all. On the other hand, I’m hearing both frustration with users - perhaps legitimate - and a threat.

VyOS could perhaps do that, yes. Of course, the consequences might be dire. Vy* may cease to be a viable platform for hobbyists, serious homelab users, educators, students, “mom & pop shops,” and pretty much the entire vanguard of tech thought leaders. It would only be a commercial endeavor, in which VyOS would then only compete head-to-head with far more advanced soft-routers already offered natively by the very logos that VyOS claims to support (e.g., VMware, Google, Nutanix, RedHat, AWS, etc.).

Now, ask yourself: how big is AT&T? Hint: the stock ticker/symbol of AT&T is just the single character: “T.” It’s huge. It’s powerful. It’s capable. So if AT&T, with its market cap of a quarter-trillion dollars, with its army of copyright lawyers, plus its direct corporate leverage of the Internet backbone and mobile base… if they couldn’t take Vyatta code dark and monetize it against the very same logos, then is having VyOS (the company) place build scripts behind a paywall really the smartest path to continued viability? Also, GPL - see below.

Is that even an option @dmbaturin? Removing source code from all but paying customers is (shall we agree?) an interesting take on Vyatta.org’s historic GPL. Or any GPL, for that matter.

Reminder, even Microsoft had to open-source parts of its Hyper-V after Vyatta’s claims that MSFT had co-mingled paid-access MSFT code and GPL’ed Vyatta.org code ten years ago.

It might be altogether simpler to offer the full GA Release ISOs for a nominal service fee - say $15 per download. Not free “as in beer” but still free as in speech. Just enough of a service fee to pay for bandwidth, hosting, and beer. Let people mirror, if they want. Make this easy. Charge whatever you want for service desk support SLAs, for professional services, and for education certification.

As I said above:

You’re just confirming my suspicion, honestly.

13

Make what happen? Compile each GA ISO myself and host a mirror of it?

I could do that, of course. But it feels like the proverbial mustache on the Mona Lisa: L.H.O.O.Q. - Wikipedia.

I didn’t put any sweat into the code. So it doesn’t feel like it’s my place to host a mirror, though the GPL would probably allow such.

Look, my goal is not to undermine the Maintainers. I want to support this project. I remain very appreciative of all the worldwide effort. My goal in posting here was to concur that it’s needlessly complicated to find, download, and use a GA “drop” or “dot-release” for my non-commercial context.

14

On the other hand, I’m hearing both frustration with users - perhaps legitimate - and a threat.
I didn’t mean it as a threat to compromise the freedom of the code in any way. To the contrary, I’m saying that we remain committed to it where many other projects are not.

I do have to admit the frustration with users. What frustrates me most is the number of people who treat the project as “set and forget”. Then they come and say “I haven’t updated VyOS for years and now I found that LTS images are no longer free as in beer”. Right. You haven’t been helping us test the latest code, just like everyone but a rather small number of dedicated people, and now you are wondering why sustainable development wasn’t possible otherwise.

VyOS would then only compete head-to-head with far more advanced soft-routers already offered natively by the very logos that VyOS claims to support (e.g., VMware, Google, Nutanix, RedHat, AWS, etc.).

I had migrated a bunch of people from those to VyOS, for various reasons. Advanced is a complex concept. There’s hardly anything but VyOS that you can run on any platform and have the same functionality. It’s also the only one not licensed per instance.

is having VyOS (the company) place build scripts behind a paywall really the smartest path to continued viability?

My point is that we wouldn’t be doing it even if it someone sent a truckload of money our way if we did.
I don’t know if it would be a smart move, but both pfSense and Observium are still in business and more popular than their free software forks, or to it seems.

Removing source code from all but paying customers is (shall we agree?) an interesting take on Vyatta’s historic GPL.

New code doesn’t link against the original libraries, so we could only make the legacy bits public. That’s exactly what Ubiquiti does, virtually all new code from EdgeOS is proprietary, so in the source tarball you will find only old vyatta-* packages with undocumented modifications and an equally undocumented daemon for interfacing with original code via UNIX domain sockets.
Right now, removing vyos-1x and libvyosconfig from public view would make VyOS unbuildable.
Of course, we cannot do that because there’s code from other people whose copyright stays with them, so we’d need their consent.

It might be altogether simpler to offer the full GA Release ISOs for a nominal service fee - say $15 per download.

Look, it’s not hobbyists we are hiding those LTS images from. It’s corporate users who treat the project as freeware otherwise. We have discovered quite a few big names using VyOS by putting the images behind the paywall, and they never donated the project when it was a free download—for various reasons, e.g. because they have a process for buying things but not for sponsoring open source projects.
Hobbyists can help us with testing rolling release builds, writing docs, writing code—and get access to those images for free. That’s much more valuable to the project from $15 once a year.

By “make it happen” @syncer means making a reproducible build happen. I do believe it’s doable, and I believe we all can do it. But that’s quite some work, from design to actual scripts.

15

That’s a thoughtful, quick, articulate response. Thank you.

Nevertheless, I would encourage all to meditate on the fact that it’s still too hard to end up with a known-good Release ISO beyond the paywall, no matter how many hoops the Maintainers make users jump through. Your answer is, in essence, “Hey, we’re incentivizing better group participation by forcing any free-riding Muggles to download ‘rolling’ rather than LTS’.” Two basic problems with that:

  • The users from whom you seek participation become incapable of comparing rolling build (mis)behavior to last-known-good GA behavior. Indeed, there’s not much stopping a user from designating an ISO as Release 123.5678.9 in the docker ./configure, so many users won’t even know for dead certain what version they’re running, since “show version” relies on the ISO. Garbage-in, garbage out.

  • Pretty much all successful open-source platforms have a silent majority of boring Muggles as the user base. Some Muggles may later choose to participate in code development, documentation, etc… You’re alienating the silent majority. I mean that in the literal sense of the word, you’re alienating “Maintainers in the larval stage” by estranging them from working with reliable product in the first place.

This is a tough nut to crack.

1 Like
17

Which exactly open-source projects you manage currently?
You seem to like to give advice, so I expect you have plenty of experience in the subject.

18

That felt like an ad hominem response to folks who question, as @dws does, “how to get a certain version.” That’s a simple question, really.

Returning to the subject at hand, then, QED - we’ve proven here that it remains difficult for the vast majority of potential users to instantiate a known-good build in a home lab. It’s therefore difficult for such users to participate in this open-source project with the simple confidence that at least one VyOS instance is LITERALLY stable.

That used to be possible with Vyatta.org; it no longer seems so. Nor is it reasonable for any firm/group to ask $1,500/ yr for the confidence of simply downloading a “dot release” of open source GPL code that one can compile and use without assistance if one is not seeking commercial (i.e., ITSM Service Desk) support or pro services.

It should benefit any open-source project to have more homelab participants/contributors/users than less, even if they are dabblers. Yet now it seems clear from @syncer’s “unwelcome mat” that making the long-term-stable (LTS) branch unstable is indeed intentional, that it acts as a kind of commercial gate. Certain people here think that’s a valid approach.

I have long held this project and its participants in incredibly high esteem. Thank you for your difficult (and smart) work, and thank you also for the incredible effort by ~20 years of your predecessors.

I am unlikely to continue experimenting with VyOS, or to participate further.

2 Likes
19

what is the Build Commit ID of the official 1.2.4 release? am I right to assume that if a homebuilt ISO shows the same Build Commit ID that I’ve got the real deal then?

20

Not sure what exactly you expected.
@dmbaturin already explained everything
no time for pointless discussions

21

Well, one thing that might be of use is this:

https://snapshot.debian.org/

This means that the Debian repositories can be versioned by date, which means that if the build scripts use the build/release date then the builds should (theoretically) be reproducible.

I’m very interested in this (been a Vyatta → VyOS user for a long time, as well as an EdgeOS user) so when I get some time, I’ll take a look myself. In the meanwhile, I’m just throwing it out there, in case someone gets time before I do.

1 Like