Replies: 14 comments 78 replies
-
|
What do they use to build automatically? |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
It's just a draft - only the build script part but the structure is consistent so you iterate over each directory and call |
Beta Was this translation helpful? Give feedback.
-
|
Some more information about how they likely will use the new scripts. Thus how they plan to replace other parts of Jenkins. https://github.com/vyos/vyos-build/blob/current/.github/workflows/trigger_rebuild_packages.yml By looking at this it seems they will use GitHub workflows to trigger a build via the new build scripts. The It would be trivial to write piece of python that would do the same thing - scan change-set and look for changes and trigger build for specific package if applicable and send it to reprepro. That's why we don't even need to worry about how the VyOS team does it. It's easy to write standalone replacement that doesn't use GitHub workflows. The new build scripts doesn't seem to be complete tho since they work with what vyos-build repository contains, thus it doesn't include any other package that is being built from it's own repository thus I don't believe the new system can build all packages yet. Perhaps this is testing phase before it's used to cover every package? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I wonder why they want to keep the action secret |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I think of the The Jenkins vs new equivalents looks like this:
|
Beta Was this translation helpful? Give feedback.
-
|
We could make the new implementation like this:
I'm not worried about the missing pieces since we would need to rewrite those anyway (unless you want to use GitHub workflows - I don't). I want script that you can call where you want. I take this as opportunity to ditch the CI/CD - if we are getting rid of Jenkins we should get rid of the GitHub workflows/any other CI/CD too. This wasn't quite possible with Jenkins since part of the build.py is inside of the Jenkins pipelines. Thus there was no unified way to build packages standalone. The great part is, that when the VyOS gives you universal build scripts, in the shape of the build.py, then it's easy to write your own scheduler/builder around it without burden of release-to-release maintenance - once you write it, there is no need to change it since the part that changes with VyOS development is the definitions under build.py. It's still early days tho. It makes sense to start any work after the system is complete - when you can build all circinus packages and assemble usable reprepro repository until then I see the current state as experimental phase. |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
I see 😊 I'm haven't really been working with python, so I don't think I can help that much with that part. |
Beta Was this translation helpful? Give feedback.
-
|
The setup would be reduced by a lot but some parts stay - like the apt install dependencies - docker/reprepro/... and building vyos-build container but the whole Jenkins part will go away. Although some of the complexity will move from the setup into the logic that will replace what Jenkins does now, so it won't be that simple. It's impressive what did you manage to do with the bash and I like bash since it's more accessible to more people but at the end it got so complex that every time I want to do something with it I spend most of time dealing with bash idiosyncrasies rather than working on the task. The result is great but the robustness and ability to debug is still lacking and there is no reasonable way to make it as good as other languages are by default. You need to write hundreds lines of boilerplate code to make bash somewhat robust as other languages are where you don't need to do much at all for the same result. That's why writing and maintaining complex bash seems like waste of effort to me. If we need to write new implementation it makes sense to also switch to language that is better fit for complex tasks. Python is not the only option but it seems the most common choice after bash for scripting - Linux distributions use python for scripting, thus it's installed by default in Debian and VyOS uses it too more and more. Another popular scripting language would be Perl and less so Ruby but I like and use python a lot thus for me it's natural choice. What would you prefer (besides bash) for scripting? |
Beta Was this translation helpful? Give feedback.
-
|
I normally do all my scripting in powershell, simply do to the fact that everything is an object, which makes so many things easier. What I fear about just switching to something running in the background with cron is that if something goes wrong, how would people notice it? (Instead of just 1 package never getting updated). Jenkins has to go, I agree, I'm just wondering if we need to replace it with something else (or maybe still use it, just have it call the build.py scripts, like they do it github actions?) |
Beta Was this translation helpful? Give feedback.
-
|
I don't feel powershell is something many Linux users know 😄. There is no need to use CRON if you just want to build one-off, then you can invoke the scheduler script in terminal by hand. This would be improvement over CI/CD, because many people don't need to keep repository up to date all the time, they want to build "on-demand", this isn't exactly possible with Jenkins. I think this covers most of the people thus most of the users don't even need to invoke the CRON, they can run the scheduler in the terminal when they want. This would be big upgrade and main motivation why you don't want CI/CD replacement for Jenkins. If you want to keep repository up to date for the purpose for hosting public repository for others then you can call the scheduler via CRON and thus you get the Jenkins behavior but that's your choice, it's not forced as is with CI/CD like Jenkins. By default in Linux CRON will send notification to your user e-mail (via /etc/aliases) if any stderr occurs. I do this often when I want very simple error handling, where I set the Python logging to write anything with WARNING or "higher" level to stderr and thus only "INFO or bellow" level goes into stdout. Thus I get error message/stack trace notification when something goes wrong. Extremely simple yet powerful. If you want more user-friendly notification like "these packages failed, here is the log" then there is simple way to send custom e-mail notification via Python built-in SMTP library. Notification is so much more useful than just to show the error somewhere. You of course have one log file where you can see everything, so if you interested if something failed it's straightforward to check one file. If you don't want notification you can hook the log to whatever build iso script you are using, so the build iso will tell that CRON failed and why and show you the log path. This would be lot of work with bash but it's easy with python. The Jenkins error handling is not user-friendly. Since there is no easy way to see that job failed. The default view literally hides this from you. The build log also sometimes hides failure if the failure happened some time ago (because of branch indexing spam). You can install additional plugins and make custom views to make this better but out of the box the Jenkins is pretty bad at telling you that something failed and if you know what failed it's not easy to get log file with all context - you need to find the job/branch/run and get log there (and you need to avoid the dummy branch indexing runs...) and you need to also check the uncron log to get complete picture and I know this is issue since users reported that Jenkins showed all green happy yet there was no .deb. The ability of Jenkins to report there was failure and show helpful information isn't that great and the uncron async processing doesn't help either. This would be improved by whole lot if everything was handled by single script and not by two independent services. In result if we ditch CI/CD we can make it so much better! |
Beta Was this translation helpful? Give feedback.
-
|
Yep 🙂 Hope your python skills are better than mine (mine are non existing) 😃 |
Beta Was this translation helpful? Give feedback.
-
|
New development T6754: Delete Jenkins build packages - seems like current branch is transitioning to the new GitHub Workflow + Python build system for good. So far no progress for circinus nor sagitta. The equuleus likely won't get the new build system ever. This is tied to the change of APT repository vyos/vyos-build#780 - this tells me that they now have whole repository built by the GitHub Workflow (for current branch). It's still mystery how they build packages outside the main vyos-build repository. Even the current branch has still bunch of dependencies on packages that have their own repository and I didn't see any build script as the vyos-build has for the standalone packages. I'm missing something? For example https://github.com/vyos/ipaddrcheck was updated recently by adding new GitHub Workflow and this Workflow points to vyos/.github/.github/workflows/trigger-rebuild-repo-package.yml and this Workflow points to the mysterious They could invoke the build.py directly for "simple builds" but this script expects package.toml configuration and I don't see any .toml file that would have this configuration for these packages. So they use some other build system like invoking dpkg-buildpackage directly or what? Doesn't make much sense to me, likely I'm missing something... Do they have two separate build systems (like the one build.py and another one in pure GitHub Workflow/other hidden scripts? The new repository has these packages: And these need to come from somewhere... I'm blind or it's just not public? EDIT: I just noticed that what both packages (ipaddrcheck, vyos-1x) share is that they don't have custom build, they invoke the Jenkins library with null command and this has fallback to dpkg-buildpackage. Thus for these packages they use the same method, that the hidden GitHub Workflow just calls |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Hmm... so maybe they reconsidered some of my suggestions from https://vyos.dev/T6483 (closed, invalid, no plans, go away evil hijacker...) and will make more use of Debian tools to build packages after all? Or do you see some attempts to make things more difficult for those without $$$ subscriptions? |
Beta Was this translation helpful? Give feedback.
-
|
The This doesn't have anything to do with the Debian source package policy. VyOS uses Debian package build practically with every package but mainly for the binary package part and I don't think much changed with this decision not to invest into missing source packages. They actually have a plan to workaround the corresponding source issue instead? It's quite possible that the build system would be implemented fully by the time circinus is released and thus when equuleus support will presumably end - even if not, equuleus support will end eventually. Thus it may not have anything to do with the risk of new build system breaking equuleus, it may be about the timing and cost. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, there is a new organization https://github.com/VyOS-Networks and it has no public repositories. Spotted in https://vyos.dev/T6708 with a comment: "All PRs created in /vyos/* repos should be mirrored to /VyOS-Networks for backporting into LTS branches." First they say:
and then they seem not too happy someone actually has done this, how nice... |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
There is no concrete evidence that they will make future LTS development private but what they could be building private GitHub development/build infrastructure for? For fun? Historically anything related to VyOS as the OS itself was public, this unfortunately changing fast and although nothing critical is private yet. There is clear direction since the closure of the repositories and I do believe once the GitHub infrastructure is done, that's where the real change begins. I don't see any other reason why would they have private fork of vyos-build/vyos-1x/everything for. There also the hint of future development of LTS branches in the hidden organization. VyOS team and affiliated people said in numerous ways that the non-subscribers have no reason to use anything else than rolling/current/whatever you want to call it. VyOS team also stated that contributions to the LTS branches are limited to bug fixes and those are extremely rare from outside developers. I can conclude that was their realization that they don't need to keep LTS branches public anymore. The stream ideology helps nicely too because future LTS would be fork of previous LTS and thus there won't be link to the The reasons they said (and will say) are just excuses, this is just business decision how to milk every possible subscribe there is. There won't be better pricing - non-subscribers will get rolling and that's it. One big company pays more than what bunch of smaller customers would pay. If they offer the same product for less, that would cannibalize some of their higher paying costumers. The offer of support isn't enough for everyone to pay $8000 more for the same thing. That's why there won't be cheaper option unless they manage to make crippled version that would be useless for the higher paying customers... Eventually we maybe get the online image builder where we will be able to custom build rolling??? The only reason why it didn't happen sooner was that whole development was public and they are working on that right now... It really doesn't look good... The Debian LTS has 5 year support and the Freexian ELTS extends this by another 5 years (limited to the packages the ELTS supports). So if you want to use present VyOS for long time - you absolutely can, but it's not as easy, you need to possibly take care of pinned packages (and maybe their patches) and perhaps even deal with the patches of forked packages in few cases. This way in theory it's possible to extend the equuleus up to 2029 and sagitta 2033, quite the distance but not without work! They didn't even announce the news yet, so it may take who knows how long before their new infrastructure is ready, maybe they will wait for next version realease or something. They won't give any headups, they like to surprise everyone so one day it just drops out of nowhere... But if (more when?) it happens, then one should start to plan what he will have completed before the 2030... The further you will be the less sense it makes to setup new machines with VyOS that ended development. Makes sense to wait some time after the change is done. Maybe another serious fork happens, who knows, we will see, but I don't bet on it. I'm still using equuleus, I will continue to build and use VyOS as long as possible but when the change happens - that's the end and point when I will start to plan to transition away. I'm also using VyOS since crux (so I'm just on the second version 😄) and I was using EdgeOS (Vyatta fork) before then (so I'm using partially the same config.boot since 2016), it served well and it would be sad day to see it end - I take it as it did good job for as long as is did and that's the value for me. |
Beta Was this translation helpful? Give feedback.
-
|
Do you know if the stream releases will be available for people to download and use? |
Beta Was this translation helpful? Give feedback.
-
|
https://blog.vyos.io/introducing-vyos-stream
They said so. I don't think about the stream as "semi-LTS" since currently it's basically |
Beta Was this translation helpful? Give feedback.
-
|
Good question - the way I understand it is that stream will only get things merged after they are stable (Am I misunderstanding it?) |
Beta Was this translation helpful? Give feedback.
-
|
I don't think migration should be broken anywhere (including the I don't think the biggest issue with rolling is that the new features change too much, because you can happily use the The idea to back-port only final, solid and stable code is great, but you need to actually know if the code is final, solid and stable and that's whole another story. If they simply back-port everything from TL;DR |
Beta Was this translation helpful? Give feedback.
-
|
It's interesting they are pointing out the replacement of Jenkins. Yet the mentioned workflow points to hidden workflow that does the build. I don't see the script that calls build.py, so currently the build scripts are incomplete, partially hidden away - even for |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
We will have to wait and see |
Beta Was this translation helpful? Give feedback.
-
|
One worrying possibility - may or may not be true, for now this is pure speculation, hopefully not true but can't be excluded - the more closed development (some source and scripts not public, available only to those with $$$ subsciptions) means it's harder to notice when some malicious code is quietly added. As the xz backdoor has shown, it might happen even in fully open source projects, but still is easier to pull off if fewer eyes can see inside, and this project is much more complex. They might get some secret offer they couldn't refuse (say from some Russian oligarchs) who will help the project financially, but want some backdoor added in return to make it possible to spy on the users. So all these changes could be intended just to hide some potential future malicious changes. As for poking the bear, I think the bear is watching us anyway, or the reaction wouldn't be so quick (a few minutes, and my reply was removed too, even though I was just helping the fellow user who turned out to be from the same city where I was studying, said nothing offensive or off-topic or defaming the project). And the fact they get so nervous even just discussing things might mean they are indeed not honest - I had a gut feeling that something is suspicious, but was giving them the benefit of the doubt. Such threats should not be under-estimated, as a side note it's not just the bear but also the panda too (as I recently learned, adding a "wifi stick "to an on-grid PV inverter gives the server in China complete control over the inverter, not just statistics to show the user nice graphs, but also write access to any registers including remote firmware update without any action from the user, protected by a super-secret password changed every day which is just "growattYYYYMMDD", fortunately the inverter works fine without any Internet connection, it was just temporary for remote diagnostics to get warranty repair). About routing performance differences VyOS vs Debian - I think it could be because VyOS has a newer kernel and (depending on hardware) some out-of-tree NIC drivers, I don't see anything else that could result in so much difference. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
I'll tip you off on a secret scheme to access all our malware-ridden LTS releases without paying anything. https://vyos.net/get/contributor-subscriptions/ |
Beta Was this translation helpful? Give feedback.
-
|
Hello @dmbaturin - yes I know, actually in the past I had access (supported the project via Open Collective, $25/month from March 2022 to June 2024) but the project has decided to terminate this. And I got some harsh words (too harsh to quote publicly), even though I never distributed LTS images to third parties or overloaded your cloud servers with image builds. I have been quite active testing, reporting bugs, discussing on the forum (until silenced because I dare to discuss some forbidden subject, accused of hijacking first time ever in my life) and in the past I had been active as open source contributor - Debian user since 1994, some projects I was working on: start-stop-daemon in Debian (rewrite of Perl script in C, much faster), maintaining the shadow password suite (login, passwd, su, useradd etc.) in the 1990s, improvements to GCC for AVR microcontrolers. I wish I could do more but real life was not easy and still isn't. And please don't misunderstand me, I didn't say anything is malware-ridden right now, I'm just worried that the current direction to more closed development might allow bad things to happen behind the scenes. |
Beta Was this translation helpful? Give feedback.
-
|
Your experience with the magic wifi stick actually makes a lot of financial sense for the manufacturer. Imagine how much cheaper is to dial up into backdoor compared to sending technician just to do little firmware upgrade or to flip couple settings! I would also think that regular customer would be happier if the inverter starts behave by itself magically than needing to deal with warranty. I don't think the manufacturer have any benefit doing any harm this way but I would fear that such backdoor could be abused by someone else. Then your inverter would join the IoT DDoS botnet for hire, maybe it would mine some bitcoin too. It's unfortunate this isn't advertised as feature though. I'm also not surprised that you are bit paranoid if you have such experience. I didn't find any backdoor yet but I also don't own internet connected devices that doesn't have my own firmware. Well I do but those closed devices are from big brands and surely someone like Intel or Google knows better and they won't use YYYYMMDD password for their backdoor, maybe... BTW: It's amazing that the VyOS team always responds only to most irrelevant thing in given discussion. I also would think they have better things to do than reading this... |
Beta Was this translation helpful? Give feedback.
-
|
The hidden build script I have no idea how this works for the VyOS team unless the hidden build script has numerous conditions with hardcoded build commands for specific package - if the package needs it's own build command why this isn't a part of the repository of the given package? Why there needs to be some master hidden build script that has hardcoded build commands for specific packages? I would hoped the new build system would fix the old issues so we don't need custom patches/build scripts, oh well. Of course the libpam-tacplus/libnss-tacplus/libtacplus-map combo doesn't have functional build script either but the https://github.com/dd010101/vyos-missing/blob/sagitta/packages/libnss-tacplus/build.sh works great. With some workarounds I can build the following: List of debsIs that all? Seems like half? I scanned the vyos org and added every repository with the new GitHub Workflow to the build queue based on the workflow file. I would like to find some way how assemble the list of packages and their build script automaticaly. Maybe scanning every repository with branch is better tactic than scanning the workflows? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
There could be a separate non-public directory containing per-package build scripts, replacing what was in the deleted Jenkinsfiles, called from the single master script by package name. Those who can get the LTS images would also get the build scripts, to minimally comply with the letter of the GPL. All pure speculation of course, basically Jenkins was expected to be enough of a barrier to building own images, until it wasn't a barrier anymore (thanks!) so the arms race continues... |
Beta Was this translation helpful? Give feedback.
-
|
It's more like just few pieces are missing now. All packages in the vyos-build repository build just fine as it's very friendly thanks the build.py, great work there! But that's where it did stop... The rest packages are sloppy and you need to use guess work to build them. I don't think anything now or anything before with Jenkins was designed this way. It was just made for their internal use. So it's not intentional. It wasn't meant to be used by anyone else and I would hoped the new system would fix it and it did, partially, kind of... Remember we talking about the current and circinus, so there is literally no reason to make it hard to compile, because circinus images are now free to download and current of course should be build-able as the development branch. |
Beta Was this translation helpful? Give feedback.
-
|
OK we will have to wait and see, perhaps it's just work in progress and some missing parts will be done later. Not sure how it may affect sagitta as they seem silent on any 1.4.1 release plans (someone got nervous when politely asked on their forum) despite some changes already on that branch. |
Beta Was this translation helpful? Give feedback.
-
|
I do not expect that something with the new build system will improve if it's already working for them. Every task related to new build system was also tagged sagitta so I do expect it would be implemented at some point. That's why I'm starting to work on this now, I'm expecting the saggita Jenkinsfiles will disappear soon. The workboard for 1.4.1 is loaded so it doesn't seem to be close to release. Maybe they will reassign everything to 1.4.2 though. It seems like sagitta is on back burner because of the CI/CD/build changes. |
Beta Was this translation helpful? Give feedback.
-
|
It shouldn't be any more complicating than fleshing out package.toml files for the external repos and using build.py to build those packages. The wrapper script would just detect if the package build directory already exists, and if not, source the appropriate package.toml, or even simply just calling the build routine via bash rather than build.py. I maintain a separate cloud init routine and then a general common routine which has an exception for libvyosconfig and vyos-utils, which each call for opam to be set up with this line: cloud-init is simply Otherwise, there's nothing particularly difficult and the answers are already public knowledge via the Jenkinsfiles. Mmm, don't forget to check if build.py is an absolutely incredible evolution to this process in my opinion. For what little it's worth from me, hats off to Mr. sever sever. |
Beta Was this translation helpful? Give feedback.
19 replies
-
|
It wasn't easy, the 1.4.3 was easier but at the end it's there.
The tacplus packages were for sure the most mysterious and required the most work to be compiled compared to others yet I'm sure nobody who will compile them will actually used them... |
Beta Was this translation helpful? Give feedback.
-
I set up with Excellent work on this new system. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
The dpkg-scanpackages is cool. I didn't even know there was simpler method how to setup APT repository or specifically that the Packages are enough, I was thinking the whole structure was mandatory, I guess because every repo looks like that. I do like to do things driven by principle more than "it works" and so if you are starting from scratch why not to cover the corner cases. But if you already have something that works then it works! This very much applies to my personal projects where no care is given since it's just for me and even though some of it should be rewritten I would never redo something if there isn't a serious reason for it, so I do have some real legacy stuff still running. I know I would do it totally differently now but until it breaks I can only wait. I don't have time for it anyway. The packages are few GB so indeed it's insignificant compared to rest, my build OS has 100GB occupied, the docker has 55GB of it for some reason and the rest is spread across many files. Indded few extra packages wouldn't change much. |
Beta Was this translation helpful? Give feedback.
-
|
They've recently published new images so I recently did a |
Beta Was this translation helpful? Give feedback.
-
|
I keep the images and containers in check, so I don't usually need to do prune on them. I don't quite like the system prune since I don't see what it removes until it's done, for example one time it deleted "unused" network I used for temporary containers so the "unused" qualifier isn't always good match for everything, mainly when it doesn't tell you until it's too late... Overall the sizes are expected but the build cache... It's always the build cache for me and it doesn't help that the system prune doesn't even touch the cache... Now /var/lib/docker has only 18GB and that's okay since I have 4x vyos-build there. The only container is the local docker registry for the Jenkins. No idea how the registry can be cleaned, doesn't seem to have any CLI. You can always delete and rebuild I suppose. |
Beta Was this translation helpful? Give feedback.
-
|
There is one snag with the The Here is Packages of the given circinus repositorySeems like the generic flavor is the culprit https://github.com/vyos/vyos-build/blob/circinus/data/build-flavors/generic.toml#L9 |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
Great 😃 the fewer components needed to set up, the better. |
Beta Was this translation helpful? Give feedback.
-
|
Just a note about xen-guest-agent that it is changing rapidly because it's a new project to make a single guest agent replacing the old xen tools for both the commercial product (Citrix Hypervisor, now called XenServer again) and the community fork (XCP-NG, open source and free to download LTS, optional commercial support) what was born after the original open source project was closed. A bit similar story as with Vyatta, only this time it was Citrix that wanted more $$$ - VyOS(tm) is not to blame for that :) |
Beta Was this translation helpful? Give feedback.
-
|
I also added the de-branding (same functionality like with previous build method). Also the logging is much improved compared to old method. Now there is log file that contains log of everything (of the script, the docker, the reprepro, ..) and if something fails the script tells you where the log is - this should improve the previously seen situation where build failed and people did have issue finding the cause because the logs were hidden and in multiple places. Also everything is executing foreground, so you can see the failure of anything clearly, most of time you don't even need the log. The Jenkins and uncron run in background and thus they can hide the failure in such way you didn't even know it happened. Since there is no dependency on any system service or networking this should make the script much more portable - there is no reason it couldn't run easily on arch or gentoo for example, if you install the dependencies manually via other package manager. Yes, even the arch and gentoo have reprepro, the tool for managing APT repositories, they even have debootstrap - tool for installing Debian into directory, for some reason.... Also the script doesn't touch /etc now, so it's much more portable in this sense too, it's self-contained as much as it be, of course the docker dependency still exists, so script needs to control one container of the docker but that's the only part it touches outside it's directory. It doesn't need it's own user, it can it run as any regular user (well it needs to, if it runs as root this breaks things, so the script refuses to run as root). Thus it shouldn't interfere with anything, previously we changed the networking, the /etc of couple services, we installed additional services so all this heavy interference is gone with the new method. |
Beta Was this translation helpful? Give feedback.
-
|
You'll need to debrand |
Beta Was this translation helpful? Give feedback.
-
|
Already future-proof. |
Beta Was this translation helpful? Give feedback.
-
Time to move on, I suppose. I'll be pulling their images out of my infrastructure imminently. |
Beta Was this translation helpful? Give feedback.
9 replies
-
|
Yeah, that was more of a joke, it's clear there is no way that free subscriber would have chance to do this for long. Maybe they would even terminate paying subscriber, who knows. They have the right to terminate subscription as much as anyone has the right to make the source code public... The pfSense is for me in the same boat as the VyOS is, the same story, clear direction to closed-source version and open-source version is taking back seat at best or missing features at worst. If you can work with RouterOS then I don't think there is even question of cost, since there is no way you can get x86 version of what MikroTik sells with ARM for less, let alone to pay for software subscription... I personally see Debian as my way out, eventually... I'm willing to give the stream branch a go, since it's way easier to upgrade-then-rollback and see, than porting everything to anything else... Who knows, maybe the stream will work, I didn't try it and it doesn't exist for long so there is still a chance. Time delay doesn't really matter, because if there is something important then there will be release and thus stream too. I'm still running equuleus and I don't mind that it doesn't have update every month at all. |
Beta Was this translation helpful? Give feedback.
-
|
While they could always terminate all free subscribers at once (again...), it's not so easy with paying subscribers. They would need to have some proof of the source of the leak - will the LTS images have activation keys, and phone home to ask for license? It may well make sense to backport fixes from new stream releases to the last available sagitta branch. It's LTS so mostly fixes no new features, part of the work is done by Debian itself (like the RegreSSHion fix just after 1.4.0), and they usually described changes in detail - unless they go totally "bug fixes and performance improvements" like most mobile apps updates... |
Beta Was this translation helpful? Give feedback.
-
|
I've just completed moving off all non-routing functionalities and can begin investigating alternatives, probably later this week. I have a should-be-working nftables configuration from my tests back in May.
Hopefully the same ~52 contributors keep the project going. Seems even more unlikely they'll get substantially more. |
Beta Was this translation helpful? Give feedback.
-
Imagine how hard that will be... There is one annoying subscriber that ask after every release for source and shortly after it's on GitHub, who could be doing that... Remember you need to ask them to give it you and if you ask every release, then there is only one option who does the leaks because the one person would be the only one...
The point of that sentence was to prove that the open-source doesn't do enough not to talk about developers. It was just another justification why the open-source is worthless for them... Also imagine they would keep up the opencollection subscriber program and everyone there would qualify for source code. It didn't make much sense back then but with hindsight it makes so much sense... |
Beta Was this translation helpful? Give feedback.
-
|
Well they could even physically ship the code on a CD-R for the cost of copying and shipping... Simplest thing to do would be to give the subscribers GH accounts read access to the private repo. They may never know for sure if it's not one of their own developers who leaked it. Some of them could see issues with the project, but be afraid to speak up against the boss (and be told to leave). It might happen that at some point some of them will leave and start something new. Some of the VyOS people were former Vyatta people too... |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Do I understand correctly that if I continue to build equuleus and saggita using this vyos-jenkins repo I will still be able to get an iso with the up-to date base Debian, and only vyos-specific packages will stay frozen and outdated? In other word, we can basically continue to build and use both equuleus and saggita with more or less reliable manner, when at least the core OS components are updated? Or, this system will cease functioning, say because some specific packages can never be built or something? |
Beta Was this translation helpful? Give feedback.
14 replies
-
Looks interesting, first install 1.3 on a new machine, apply the existing config then upgrade to 1.4 to migrate the config and save the contents of /run for a starting point to use on Debian 12. I'm doing the migration while also migrating to newer hardware so can keep running old and new machines running at the same time for a while.
Involved only recently, the original author (Dmitry Kozlov) has his repo https://github.com/xebd/accel-ppp so it should be possible to compare what has changed in the new one https://github.com/accel-ppp/accel-ppp - it's a bit of a mystery to me that GH doesn't show the new one as a fork of the old one, looks more like it was copied not forked, but old history (since 2010 or so) is still preserved. It could (just my speculation) have been done just in case Russian users are banned from GH (by GH and/or by Russia). |
Beta Was this translation helpful? Give feedback.
-
|
The best way (I know of) to compare two projects is via git with two remotes like this: Although you wont see anything useful since xebd/accel-ppp is copy of accel-ppp just 8 months behind. The last commit from xebd repo matches a commit in the accel-ppp accel-ppp/accel-ppp@dbffa39 so it's the same tree. Thus the xebd one now looks like personal repo of developer and the accel-ppp is where all the collective development happens. Why it's not a fork? If the development didn't originate in the accel-ppp then it doesn't make sense to move it there via fork since you moving the main repository. It would look confusing if a "fork" would be the main repo. The xebd repo would be the fork in this case if this was the usual arrangement. |
Beta Was this translation helpful? Give feedback.
-
|
The xebd repo is certainly older, release 1.10.0 tag from 2015, on sourceforge it dates back to 2011 and earlier, linux/drivers/net/ppp/pptp.c from the same author was in 2010. Oldest pull request in the new accel-ppp org was in 2020. So it looks like VyOS is taking over accel-ppp from the author, in one email to me syncer mentioned they plan to make it a commercial product. If it happens, I'll probably continue in my own fork of accel-ppp as I use it and don't have good alternatives, and have already spent some time on it (still want to fix T4600 though it's not as easy as it seems). |
Beta Was this translation helpful? Give feedback.
-
BTW, how do you configure network interfaces - ifupdown, netplan? Not sure exactly how VyOS does it, /etc/network/interfaces only has loopback. It's not in frr.conf either, I have a unnumbered interfaces (a few interfaces have the same IP with /32 netmask as the loopback) and I don't see that in any generated files, do they configure interfaces directly while reading the configuration commands? |
Beta Was this translation helpful? Give feedback.
-
|
That's why the idea about /run isn't complete story. There are some parts that are configured runtime - iproute2, netfilter, ethtool, proc/sys... There is no config for those, well the config for those is the VyOS config.boot. The config.boot is parsed and translated into abstraction. The abstraction then translates into some Linux command. If I'm interest how VyOS does something then I will go from the command I call in VyOS and transverse the path from the command to the specifics the command does. Simple example - you call (conf) set interfaces ethernet [if] address [ip]. The conf_mode/interfaces_ethernet.py calls abstraction from "Ethernet"/"Interface" classes and in those classes you actually see what the VyOS commands do like in this example the final ip add add. There is no "best" way to do this. You can use ifupdown, netplan, networkd 😄, NetworkManager 😆, ... It doesn't really matter, at the end it's just wrapper for iproute2 and various other parts, choose what you like, what you know, what works for you or write your own wrapper as VyOS did if you need maximum flexibility and control. The netplan is higher abstraction (based on networkd) and was created to address some ifupdown limitation, so this gives you some advantages but sometimes simpler can be better - this depends on the complexity. The more the complex the setup is the more you will benefit from more abstract wrapper like what netplan is. As example the Cumulus Linux uses ifupdown, so there no reason why you can't build networking OS on ifupdown. There is no wrong answer here, it depends on your preferences and use-case. I personally mix ifupdown and my own wrappers that call iproute2 directly where I need dynamic behavior or network namespaces. |
Beta Was this translation helpful? Give feedback.
-
circinus branch is what probably going to become Stream. However, no more trust in their words what Stream will be, how it's source code will remain open, how it can be built in the long run, and what functionality will be removed from Stream to be reserved for LTS exclusively. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
This matters only if you want to use VyOS for new projects - then don't do that - build your own router if you can or find something else. I'm using VyOS already thus for me trying circinus/stream is straightforward, if it fails then I will be at the same point as now - it won't change anything - my investment into circinus is nothing in comparison what migration to something else will be, so why not to try? If I will end up in the same situation just some time later then be it. |
Beta Was this translation helpful? Give feedback.
-
|
vanilla Debian (or one's favorite distro) is a natural choice for those who can |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
New VyOS package build system begins to form - vyos/vyos-build#745
Looks like they want to migrate away from Jenkins Pipeline Syntax + bash to Python scripts. The first version did have insane duplication of build.py but they are improving this to use unified script.
That's awesome! Such unified build system in Python would simplify the build environment by a lot, it would improve the robustness of error handling and also it would reduce the overhead of maintaining and testing 👍.
Beta Was this translation helpful? Give feedback.
All reactions