By the way, may I say there are several bugs of stop function in vyos-router?

Why not use WantedBy instead of RequiredBy in vyos-hostsd.service like:

My original thoughts was quite straight forward, modify /usr/libexec/vyos/init/vyos-router as below:

Hello, @MapleWang!
Unfortunately, I cannot find any other reliable way to configure vyos-hostsd service to be running before the vyos-router. In fact, vyos-hostsd is really necessary to be running for proper work of the VyOS system, so we can consider this even from the other point of view - how to keep all services operable after the vyos-router restart?
If you will have any ideas, which can help to decrease the overall impact of this situation, we would be happy to get them.

Really thanks for your reply. It's nice to have this fix. But to be honest, crash of vyos-hostsd is not so big deal for me, what really concern me is that restart of vyos-hostsd is followed by restart of vyos-router.

Hello, @MapleWang!
Thank you for pointing our attention to this issue! It is really bad that such simple action as changing hostname in some cases (well, in fact not only this but it is easy to reproduce) leads to the whole router crash.
The problem consists of several parts:

1. In old systemd versions (which is used in Debian Jessie and VyOS 1.2) exists a problem, when during a restart of systemd-journald all pipes between this daemon and systemd services are disconnecting.
2. In vyos-hostsd, which is responsible for hostname and DNS and controlled by systemd we used print() for logging and debug purposed without enough handling of errors.

So, when arises the situation when there is no PIPE connection between vyos-hostsd and systemd-journald, vyos-hostsd not able to print messages and crashes. :(

I found a easy way to reproduce.

There are things that should be simply incorrect grammar, and this is one of them, as of me.

https://github.com/vyos/vyos-build/pull/46

I'm using VyOS 1.2.0-beta1 (lithium) with a 1 GB HDD on ESXi.

I‘m using VyOS 1.2.x wirh a 4GB HDD on ESXi

The renderer works now (for a long time already, even), so it's time to close this task finally. ;)

It looks pretty clear from configuration point of view. Actually this request was made to avoid potential security breach if somebody doesn't have correct acl on wan facing interface.

As soon as someone sets set system ntp allow-clients address 172.16.0.0/12 we act as NTP server for this network,too. It's a bit odd that this node is under system but ... it is as it is.

that is weird,
i was under impression that we have it as client.
So it perfectly make sense have it under service

@syncer we do offer NTP as service (unfortunately it's unter the system tree instead of service.

@c-po i think we not offer ntp service as of now, but i think maybe we should?

We already have set system ntp allow-clients address 172.16.0.0/12 which can become a brother to a new command named set system ntp listen-on.

I agree with the above, this is actually how I'm dealing with custom options with dhcpd at the moment, however the same can't be done with openvpn as the functionality to include files doesn't exist within openvpn's config format, whereas it does with dhcpd.

We have thing like this in dhcpd's config - there you can state something like "subnet-parameters ... include file".
I was thinkking a little bit on it and came to the following idea - may be we should implement general syntax for stanza like "hey, vyos, I have config file for this service, please use it as is, but I still need the service to be operated on by vyos CLI commands". How do you think, would it be a good option to implement @dmbaturin?

Not just for inputting alot of commands, but making it possible to simply specifiy an opevnpn config instead of having to re-implement every possible openvpn setting using the VyOS syntax would be a huge benefit.
Not to mention the automation aspects.. copy config, load it. done.

Considering JSON's a standard that's quite close to the VyOS syntax, i don't see why maintaining another nonstandard format is needed when JSON is available :)

@sebastianm In VyConf it's going to be fairly easy (ok, possible at least) to implement different input and output formats, so chances are we can add | display json or | display yaml filters if there's demand for it.

To my mind... I'd rather keep a compatible syntax than a new one, even if there are benefits in terms of uniformity and parsing.

I say don't change it (keep it the same as it's in 1.1.7). I'd consider YAML or JSON (in that order) though. (I am/was lylylyly on IRC).

Following a discussion with @dmbaturin in #vyos, I'm to work on this puppy.

I think we can just reference it directly.

In that case, BatString can just be added as a dependency, I guess, and we can call upon that function to sort as needed? Or would you still like a specific function for node sorting?

I've just done a quick test of the BatString.numeric_compare, looks perfect.

Depending on your feelings toward batteries, we could either use BatString's numeric_compare or just crib the implementation of that function (with all due credit given, of course).

I like this kind of problem.

Already implemented in Config_tree.

This has nothing to do with vyconf. Please move it out of the project, and to vyos 1.2.0

Protobuf schema has been written.

I'm a "NO" as a network engineer with a bunch of different brands already XORP style, or as close to JunOS as you can get it the best. Yet another (Similar) config style would be way too much frustration for most of my peers to even consider.

@dmbaturin, you can probably assign this one to me, if you feel comfortable doing so. I think I'm nearly done. I'd just like to put together some decent test cases before making a PR.

Well, my vote is "No", because if for small configs it's OK to have just intent-expressed syntax, if you have huge one, e.g. several pages - if you omit prefix before, say, 55, you will have to guess from context, if it is a vlan or preffix list entry, or VRRP group or whatever.

The suggestion from @rps (XORP style) seems to be the best way from my point of view:
https://phabricator.vyos.net/V3#51

With respect to the concerns I mentioned above, I've voted no.

@dmbaturin, Im with you on the aesthetics, and the readability. In the firewall ruleset example I still feel that the first is easier read than the second. Are we talking hundreds of lines to parse the former vs the latter? It seems like the later, across a whole config would at 10-20 lines if not more depending on the complexity. I for one am interested in seeing as much of the config on one screen, vs needlessly needing to scroll. As for your Q on pfSense, I've had to edit the xml configuration file by hand based on how pfSense sorts VLANs based on their add date vs numerical value.

@tmartinson Well, you should change your vote then (votes are not final here, for the better I guess).

I keep coming back to a sense that dramatic syntax changes are very damaging and disruptive to users. My fear is that we'll be spending years explaining to people that they're looking at old documentation or examples and that they don't have their curly braces in the right place. Or that we'll alienate a segment of our user base that is averse to change.

In the example above, I vote that the first example where name Foo and rule 10 are on the same line. It is much easier to read, and shortens up the output on the display. Sometimes with long configurations, it is easier when you can see more information on the same screen without scrolling.

@systo Just to make sure you are looking at it the right way, in the large it's actually less verbose than old syntax. The vif may not be the best example but firewall would make it apparent:

As an end user, I just keep coming back to the verbosity of the syntax, and the divergence from all the other established command syntax in this space. VyOS doesn't have the following to do it differently, as it adds another barrier to adoption. Its a subtle change, but it has a long reach, especially when luring former vyatta or EdgeOS converts that want to roll-their-own, vs buy MIPS hardware. While I understand it may save coding time in the end, I'm trying to avoid the verbosity that is pfsense, and awall/shorewall. I bet if you asked a room of non-vyos engineers, they would prefer the first syntax with a much higher percentage, but alas I digress.

Any change that imparts simplicity for the coding ahead is worthwhile. Time saved in the parser's reduced complexity can be spent in other ways.

@rps An serious issue with "interfaces { eth0" is that when there is no parent subtree of all ethernet interfaces specifically, we don't know which script to call when something in "eth0" changes. We'd have to have one big script that handles the whole "interfaces" subtree, which is very problematic when it comes to adding new interface types. If eth* interfaces are children of the "ethernet" node and tun* interfaces are children of the "tunnel" node, it's easy to attach ethernet script to the "ethernet" node and "tunnel" script to the "tunnel" node, if we want to add "openvpn" later, we won't have to modify that large script to accomodate it

I haven't voted yet because I haven't decided ... It's a big change.

@rps No, that's not the biggest challenge. Semicolon at the end of leaf nodes makes them unambiguous enough and easy to tell from tag nodes (this is especially bad with valueless nodes by the way, think "disable", colon wouldn't help there, but semicolon at the end does the job). The biggest challenge is that with "ethernet eth0" the parser must be fully stateful and capable of tracking which parent nodes it's already seen. "eth0", "eth1" etc. are really children of the same node called "ethernet", but in the config they appear separately. Consider this unusual but logically valid config:

@rps this distinction also seems to be easy in the original proposed solution by @dmbaturin because key value pairs are not followed by '{' and the rest is.

From a parsing perspective the only challenge tag nodes present is that you can't easily distinguish between "key value" and "key tag" without context. "key" and "key tag value" are fine. Using a ":" you get "key: value" vs "key tag" which removes the ambiguity.

@dmbaturin I understand that the discussion is "unit 0" vs "unit { 0", what i meant was that i could be an option to keep following the JunOS style as much as possible to maybe enable more interoperability.

Well plain JSON would also be an option then :-)

@Merijn I'm still not sure why JunOS has that "unit" thing. To me it looks redundant, redundant ©. Though what we are discussing is "unit 0" vs "unit { 0" grammatic distinction, rather than specific syntax of ethernet interfaces.

The XORP configuration syntax (which Vyatta initially built upon) solves the parsing issue with the simple introduction of a ":" as a delimiter between keys and values.

In the blog post #7 i liked the address [ 192.168.2.1/24 10.10.10.1/30 ]; part. But since i work most of the time with mixed JunOS and Vyos environments a mostly the same syntax would be very nice :-)
However JunOS would be:

I was thinking that the variable would actually be "vlan-id 99". That was written simply to make it easier to read. But if it will be the top of a node, then we end up with vif, vlan-id. Which is redundant, redundant. In that case I would drop the "vlan-id" portion all together. It is only there for esthetics.

@tmartinson No, "vlan-id 99" is the old style. And, at that stage we don't know if it's ethernet or not.