Software appliance configuration framework
Jan 3 2020
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:
Jan 2 2020
My original thoughts was quite straight forward, modify /usr/libexec/vyos/init/vyos-router as below:
Dec 31 2019
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.
Dec 20 2019
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.
Dec 19 2019
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:
- 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.
- 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. :(
Dec 18 2019
I found a easy way to reproduce.
Dec 17 2019
May 3 2019
There are things that should be simply incorrect grammar, and this is one of them, as of me.
Apr 16 2019
Feb 26 2019
Nov 13 2018
Sep 6 2018
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
Aug 4 2018
The renderer works now (for a long time already, even), so it's time to close this task finally. ;)
Jun 1 2018
May 31 2018
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.
May 27 2018
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?
May 1 2018
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.
Apr 12 2018
Apr 7 2018
Apr 6 2018
Apr 1 2018
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?
Mar 31 2018
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.
Mar 22 2018
Mar 3 2018
Oct 25 2017
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 :)
Oct 7 2017
Sep 8 2017
Sep 7 2017
@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.
Aug 28 2017
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).