blog.vyos.net

If you are in Barcelona this October, we have some news for you.

There is a plan to organize an informal meeting of VyOS users and all interested in open source routing, roughly at the same time as VMworld and the OpenStack Summit. 

The current idea is October the 17th at 19-00 for VMWorld week

and on 24th 19-00 on OpenStack Summit week, though it's not set in stone yet 

Who's in charge

TCP vulnerability and its fix

There was a vulnerability discovered in the implementation of TCP in Linux (CVE-2016-5696) that is remotely exploitable and allows an attacker to impersonate a connected user. For a hotfix on a live system, you can add sudo sysctl net.ipv4.tcp_challenge_ack_limit=1000000000 to /config/scripts/vyatta-postconfig-bootup.script. The fix will be included in the 1.1.8 release.

Development meetup

Today at 18:00 UTC we will hold a development meeting, everyone is invited to join. It was discussed in phabricator (https://phabricator.vyos.net/Q41) originally, and most people voted for Google Hangouts, so that's what we'll use. I'm not fond of it myself, but so be it.

If you want to participate, fill the form here: https://goo.gl/forms/PBarp2bPWvAncQtJ2 so that we know your email address and can send you an invite.

It will be a semi-structured format, the agenda is the following:

• 1.1.8 maintenance release and what backports to include in it
• 1.2.0 and how to go about verifying that it actually works
• VyOS 2.0 (the clean rewrite) design principles
• Strategies for attracting more contributors

Rocket Chat

Lately we've setup Rocket Chat , an open source chat platform with some interesting features, including voice support, offline logs, and more. If it works well, we can use it for future development meetings, and possibly other things as well. If you want to give it a try, visit https://chat.vyos.io

1.2.0 beta2

People keep asking about 1.2.0-beta2. The truth is, if we build some image, and call it 1.2.0-beta2, nothing will change really. You can always get the latest nightly build from http://dev.packages.vyos.net/iso/current/amd64/ and start testing it. Maybe when it's stable enough for at least non-critical production environments, we will call it beta2, but until then, nightly builds is really a better way to go.

VyOS shirts

A bit to our surprise, there was some interest in VyOS shirts (https://teespring.com/stores/vyos), but they also created a bit of confusion as to what it costs and where the profit goes.

The base cost of the shirt around $15/EUR 10, so the "retail price" is some $5 higher than the base cost. Any profit from it will be used for things directly related to VyOS, such as domain renewals and the like (if the shirts somehow become popular enough to pay for anything else, we'll see what else we can do with it).

We need to come up with some convenient way to make the ledger public so that everyone can see what we received what it was used for.

Someone on Facebook rightfully noted that lately there's been more work on the infrastructure than development. This is true, but that work on infrastructure was long overdue and we just had to do it some time. There is even more work on the infrastructure waiting to be done, though it's more directly related to development, like restructuring the package repos.

Anyway, it doesn't mean all development has stopped while we've been working on infrastructure. Today we released a Python library for managing VyOS routers remotely.

Before I get to the details, have a quick example of what using it is like:

import vymgmt

vyos = vymgmt.Router('192.0.2.1', 'vyos', password='vyos', port=22)

vyos.login()
vyos.configure()

vyos.set("protocols static route 203.0.113.0/25 next-hop 192.0.2.20")
vyos.delete("system options reboot-on-panic")
vyos.commit()

vyos.save()
vyos.exit()
vyos.logout()

If you want to give it a try, you can install it from PyPI ("pip install vymgmt"), it's compatible with both Python 2.7 and Python 3. You can read the API reference at http://vymgmt.readthedocs.io/en/latest/ or get the source code at https://github.com/vyos/python-vyos-mgmt .

Now to the details. This is not a true remote API, the library connects to VyOS over SSH and sends commands as if it was a user session. Surprisingly, one of the tricky parts was to find an SSH/expect library that can cope with VyOS shell environment well, and is compatible with both 2.7 and 3. All credit for this goes to our contributor who goes by Hochikong, who tried a whole bunch of them, settled with pexpect and wrote a prototype.

How the library is better than using pexpect directly, if it's a rather thin wrapper for it? First, it's definitely more convenient to just call set() or delete() or commit() than to format command strings yourself and take care of the sending and receiving lines.

Second, common error conditions are detected (through simple regex matching) and raise appropriate exceptions such as ConfigError (for set/delete failures) or CommitError for commit errors. There's also a special ConfigLocked exception (a subclass of CommitError) that is raised when commit fails due to another commit in progress, so you can recover from it by sleep() and retry. This may seem uncommon, but people who use VRRP transition scripts and the like on VyOS already reported that they ran into it.

Third, the library is aware of the state machine of VyOS sessions, and will not let you accidentally do wrong things such as trying to enter set/delete commands before entering the conf mode. By default it also doesn't let you exit configure sessions if there are uncommited or unsaved changes, though you can override it. If a timeout occursm an exception will be raised too (while pexpect returns False in this case).

Right now it only supports set, delete, and commit, of all high level methods. This should be enough for the start, but if you want something else, there are generic methods for running op and conf mode commands (run_op_mode_command() and run_conf_mode_command() respectively). We are not sure what people want most, so what we implement depends on your requests ans suggestions (and pull requests of course!). Other things that are planned but that aren't there yet are SSH public key auth and top level words other than set and delete (rename, copy etc.). We are not sure if commit-confirm is really friendly to programmatic access, but if you have any ideas how to handle it, share with us.

On an unrelated note, syncer and his graphics designer friend made a design for VyOS t-shirts. If anyone buys that stuff, the funds will be used for the project needs. The base cost is around 20 eur, but you can get them with 15% discount by using VYOSMGTLIB promo code: https://teespring.com/stores/vyos?source=blog&pr=VYOSMGTLIB

Hi everyone,

The new website is now live. There are still some rough edges (typos, odd links, odd wording etc.), if you find anything like this, let us know. But overall it does what it's supposed to do, tells newcomers what VyOS is and provides quick links to downloads and other resources to existing users.

Here's an explanation of what happened exactly. Before that, vyos.net and vyos.org were pointing at the wiki host, and the wiki main page used to serve as our primary website. It means there are quite a few links like http://vyos.net/wiki/Something on the net, and simply pointing that domain at the host with the new website would create quite some link rot.

To avoid this, we've setup two conditional redirects, one redirects vyos.net/wiki/Something to wiki.vyos.net/wiki/Something, another one redirects everything else to vyos.io. So far it seems to work properly, but if you notice any issues with it, such as links that are not redirected correctly, let us know.

P.S. we added some merch(not much but we will add more soon) to our store, please check out https://teespring.com/stores/vyos

Hi everyone,

I like to joke about "wiki.vyos.net, a free encyclopedia no one bothers to edit", but there was a thing that actually made it rather inconvenient to edit for people, regardless of their willingness to edit it.

I mean the subnet captcha. If you haven't seen it, it made you calculate a broadcast address of a random subnet to register an account or edit a page. Everyone hated it, including me, and I had to add a number of active editors to a group that is exempt from it, by hand, so that it doesn't keep haunting them.

What's worse is that after a MediaWiki update it stopped working for a mysterious reason which I couldn't quickly debug, so I thought it may be a good time to reconsider it. Now there's the new reCAPTCHA instead, the one that wants you to click an "I'm not a robot" checkbox. For most users, it is trivial to solve, and it proved fairly effective at mitigating spam, so I think at least for now it may be the best solution for everyone.

Still, it's not entirely without controversy. There still may be accessibility converns and, since it's a third-party service, privacy concerns. If the captcha is giving you troubles, we still may make you exempt from it if you tell us your account and explain the issue.

If you, luckily for you, haven't seen the introduction of the subnet captcha, the story was that the wiki (a Vyatta wiki  back then, vyattawiki.net) had all its content replaced with spam overnight, and the original reCAPTCHA did nothing to protect it. We had been having spam problems for a long time by that moment, and after that event, we thought we have to come up with something that will stop spam forever, and so I wrote the subnet captcha plugin, and it worked very well. Except making edits inconvenient for legitimate users of course. Now when it's gone, I hope we'll be getting more editors.

I hope more people will come and edit some pages. We are seriously lacking in the documentation department, but if everyone does a small bit, it's not really that hard. You don't need to write big chunks at once and document complete features, a brief description and a config example is a lot better than nothing.

Hello, Community!

We have some great news to share! 

As some of you may already know, we are planning to run virtual meeting event for VyOS devs and users in near future.

So in case you want to participate, just fill up this form and of course join us on our dev. portal to stay in touch.

May admit that this summer is productive in all aspects:

Tremendous work towards VyOS 1.2 done and we going to present 1.2.0 beta 2 in some weeks! Thanks, to our super team!

We revived OVA distribution of VyOS some months ago and continued work in the direction of extensive VMWare Platform support; we also plan to deliver supported images for all other standard hypervisors like KVM, MS Hyper-V and VyOS on clouds markets for AWS, Azure, GCE.

VyOS is now available on SolidRun ClearFog device, credits for this great work to UnicronNL, this opens new applications for VyOS.

Ansible starting from version 2.2 able to configure VyOS, so if you using Ansible, give it a try! We on other hand working on standalone management library for Python.

We receive many requests regarding GUI, and yes we are listening to them. Last four months we dedicated a lot of time to studies regarding possible ways of delivery such  UI. Apart from technical challenges, there are other problems to take into account(like service providers don't want GUI, while SMBs and ROBOs show high demand). We are working to bring satisfaction to all users without sacrifices from any side. So basically yes, it will be GUI in near future, but there are not ETAs for now.  

We believe that affordable open source routing platform and NFV should be accessible to everyone out there

Want to participate???

Join us on social networks and spread the word about VyOS - Twitter, Reddit, FaceBook, Google+, Linkedin 

Participate in discussions on forum and of course join us on development portal 

VyOS is a community-driven Linux-based network operating system for routers and firewalls

Saludos,

Yuriy

Back then we used to make OVA images, which didn't attract any interest at the time and the idea was abandoned.

Perhaps it's time to do it again and gauge the interest. We made one for 1.1.7 and it's available from http://packages.vyos.net/iso/release/1.1.7/vyos-1.1.7-amd64-signed.ova and from the mirrors.

This OVA uses an embedded signature made with an object code signing certificate issued to Sentrium, to simplify deployment.

This one was made with VMware and uses VM hardware version 9. It should be compatible with ESXi 5.5 and later and VMware Workstation 9 and later.

Theoretically it may work in other systems with OVA support, but from my experience OVF, despite technically standardized, doesn't work that way. Please tell us if you've had any luck with it and if you know how to make it friendly to multiple systems.

We've had an idea to put together a testbed for testing new VyOS releases for a while, as having different people test different interoperability issues is not always all that handy, but we didn't have a place to host it, so we never even made any specific plans.

However, syncer (the other guy at Sentrium) offered to host it in his closet, so we can think about details.

The idea is to setup a testbed with a few VyOS boxes and hardware by various vendors where we can test if everything is working as expected. Ideally we'd like to offer access to every contributor so they can live test their changes, but for this we'll have to come up with some reservation system (do you know of any ready to use implementations?).

But first of all, we need hardware. We've already got an EdgeRouterLite, probably a Cisco 870, and a RasperryPi for a host simulator. If you've got a device you can part with, consider donating or leasing it to us.

What we definitely don't have:

• Some Juniper (SRX or smaller JSeries perhaps?)
• Some Mikrotik
• Cisco ASA (5505?)
• One more managed switch
• A couple more rpi's or other small boards for host simulators
  

If you've got anything else you think if worth adding to the testbed, let us know, join our conference here

Infrastructure changes always give people a mixed feeling. Nothing is exactly "the old thing but better", some long standing issues get fixed while some perfectly useful features become unavailable. I'm not an exception, and what I'm doing now also gives me a mixed feeling, but probably it's time to do it.

In any case, here's what we are up to. If you have any questions, or you spot any problems with any of new things we are going to use, please tell us.

TL;DR

Blog migration

We've been using tumblr for our dev blog since the beginning. Not so many people complained, but there definitely are problems.

• Twitter and facebook relay truncates posts at the first line instead of just posting the title and the link. This is annoying, and they are not going to fix it apparently.
• There are multiple formatting issues, some of them didn't exist when we started. Lossless image formats are always converted to JPEG, sometimes the original file is not even preserved. Preformatted text eats some symbols, especially "<" and ">". Reblogging strips the post off its original formatting, if it had any.
• Its content policy is, uhm, a bit too liberal. Not a bad thing per se, but it occasionally gets it blocked in workplace networks.

I looked into a number of options, including other services, traditional blog engines, and static blog generators. Posthaven costs $5/month if you want to host a blog there, but so far it's free of said problems and generally looks decent. 

The http://blog.vyos.net domain will be switched to here. The old blog will stay accessible at http://vyos-dev.tumblr.com as long as Tumblr is alive.

Bugtracker migration

What's even more important is that we are going to trade Bugzilla for Phabricator (http://phabricator.org/).

When we started the fork, the development process was modelled after the old process used by Vyatta, complete with the same tools. That process, and Bugzilla itself is obviously showing its age, and it's time to rethink it.

One of the greatest concerns is lack of integration with... anything, really. We still post links to commits by hand because there is no easy way to make it automatically update bugs with those links when someone references the bug number in commit message. The need to register an account and oldschool UI, things I normally don't care about myself, are also a deterrent for a large number of people. A number of people also find Bugzilla workflow itself confusing.

I've been looking for a bandwagon to jump on for a while, and Phabricator looks like the best option so far. What also looks appealing is that there were high profile cases of migrating to it from Bugzilla, including Wikimedia Foundation migrating a decade worth of content and workflow to it; Blender and GHC also use it now.

It's a lot more than just a bugtracker and includes applications for bug tracking, code review, questions and answers, a simple wiki, and more. There is OAuth support so people can register through Github, Google, or Facebook if they don't want a local account. Git integration works nicely, and the Q&A app can potentially replace the forum even.

Other maintainers at least don't hate it so far, but we are still to get any feedback from end users. Please go to https://phabricator.vyos.net/ , look around, and tell us what you think so we can reconfigure things to make it easier to use. There's also a question of migrating Bugzilla data to it. It's possible, we've been looking into Wikimedia's way of migrating the data, but I wonder if we really should migrate all data indiscriminately.

To address some immediate concerns, old Bugzilla and the forum will not be removed. They will stay in read only mode for the foreseeable future if we replace them.

We also do not plan to move the code to Phabricator yet. Unless Github becomes evil, primary repositories will stay there, and the ones in Phabricator will be mirrors.