Hello,
I’d like to understand what is the correct way to make system configuration customization that can survive after a reboot.
For example, I customized my /etc/ssh/sshd_config but I lost this customization after reboot.
The strange thing is that, for example, I was able to change the .ssh/authorized_keys and find the modification after reboot.
What is the correct way to do it? Should I rely on post boot script: /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script?
VyOS uses runtime reconfiguration script which runs just before login prompt (you can see it, it writes “configuration” word at boot time).
Main configuration file resides under /opt/vyatta/etc/config dir which is mounted to /config at boot.
Next, the script begins it’s job: it parses this configuration file and regenerates many of system configs (under /etc) on the fly.
That’s why you lost direct changes in sshd_config.
Direct editing files under /etc is not right way for serious router. Because if you start editing that 100500 files under /etc then you’ll get unique router that will be unsupportable by anyone else (even in case you’ll comment your changes). And that’s why none of networking hardware manufacturers gives low-level access to the system, all of them have some kind of standard configuration interface and standard use cases for every config line. That’s the right way even if you have just two routers.
But sometimes user gets into situation when he can’t get the things working just with standard interface. He wants to “screw that bolt a little bit more”. Then, in case of using propietary vendor hard/software, he must ask the vendor to add the feature he wants. But what the vendor will say? “No problems, it will cost $x00000 and we’ll do it in next XX months”. None of the vendors will do unique modifications just for one user. Because they’re just making money on mainstream. And that’s why nearly all of customers have an old Pentium-90 PC under Linux which is standing near coolest Cisco ASR and making one-two simple things that ASR can’t do
And here the open source can beat propietary. Do you need to screw that bolt? No problems, here’s a screwdriver, but you should screw it yourself with support of the community. And get the results public if you can.
Try to use standard VyOS configuration shell to get things working. It will work for many-many of standard use cases.
Again, the main idea of this shell is to make configuration standard to keep it supportable. User shouldn’t remeber all of config files, their syntax and relationships. And there is no any reasons to break this axiom.
If the things you need are really missing then there are two ways to make the configuration, I think:
Directly edit config files and make some script to overwrite autogenerated ones. It’s good for testing, but bad for production: in this case you’ll get unique system with all of it’s limitations.
Add missing features to the VyOS shell. It’s not as difficult as it seems, but it can be well documented and used/supported by someone else.
So, the both ways are suitable, and only you can decide which of them is right for the situation
Hello Valentin,
thank you for your reply, it was really useful for me.
What I was trying to achieve was more a minor configuration rather than a feature (for example: one of these was increase the SSH timeout) so I suppose I’m more in case [font=Courier][1][/font].
I looked into[font=Courier] /opt/vyatta/etc[/font] and, for what is my understanding, there I can also find some system files that will be used as template/replacement after the vyos boot.
What I’m still missing is the piece of code/configuration doing the coldfusion:
how could I take advantage of dir [font=Courier] /opt/vyatta/etc[/font] to be vyos-compliant?
I would use the [font=Courier]vyatta-postconfig-bootup.script[/font] to add something like:
echo TCPKeepAlive yes >> /etc/ssh/sshd_config
but, of course, I would follow a more “clean” approach.
Not only that files. Some files are generated by the script at boot time (just like /etc/dnsmasq.conf, ntp.conf in case they’re enabled).
I’ve missed that you’d installed the system using “install image”. Try to reinstall it using “install system” command.
In case of installing it via “install image” installer just copies live image (which is read-only) to HDD and kernel mounts it at boot time. Any modifications you’ll do in that image will use “copy-on-write” technique, simulating file writing to R/O filesystem. But after reboot you’re get clean image again.
Take a look to “mount -a” output and “/proc/cmdline” and you’ll understand what I’m speaking about (especially with my terrible english :))
Read-only images are good for production routers because it’s not so simple to modify them via root-kits in case of possible security breaks, for example.
In case of “install system” the whole image gets unpacked to an HDD partition as ordinary files, so they can be modified, but some of them still will be overwriten by configuration script at next boot time.
It’s good for debugging.
Another way: take a look into /opt/vyatta/share/vyatta-cfg/templates/service/ssh/node.def. There you’ll find the command that runs when parser reaches the end of “system ssh” section of config file:
end: if [ -z "$VAR(port/@)" ]; then exit 0; fi
STR="SSHD_OPTS=\"-p $VAR(port/@)\""
sudo sh -c "echo '$STR' > /etc/default/ssh"
sudo /usr/sbin/invoke-rc.d ssh restart
So, we can modify script a bit to set necessary options to sshd just like this:
end: if [ -z "$VAR(port/@)" ]; then exit 0; fi
STR="SSHD_OPTS=\"-p $VAR(port/@)\" -o TCPKeepAlive=yes -o ClientAliveInterval=30"
sudo sh -c "echo '$STR' > /etc/default/ssh"
sudo /usr/sbin/invoke-rc.d ssh restart
I’m not sure about sshd’s command-line options syntax, but I think you’ve got the idea.
Then, after restart, script will populate /etc/default/ssh file with options we’ve provided.
Take a look into other .def files under /opt/vyatta/share/vyatta-cfg/templates/service/ssh/. You’ll find that some of them calls sed to modify some of sshd options at boot time. And that’s the VyOS’s way: keep all of that modifications out of user’s eyes.
Hello Valentin,
your english is really understandable and surely better than mine.
I supposed it was related to UnionFS, I chose the install image to have more flexibility with updates.
I like the possibility to extend configuration in vyos extending .def files. I could do it by myself but I want submit the proposal to community and after implement it: I don’t want produce a personal dialect in configuration :), I much prefer define commands to be standard and included in future VyOS releases.
I’d like to learn more about the .def files and mechanism: have you got any suggestion about where start reading? (a part from reading source code, of course :).
