Should VyOS-specific shell be the login shell in VyOS 2.0?

Asked by dmbaturin on Dec 31 2016, 7:43 AM.

The question is: should the shell where you can issue VyOS configuration commands be the login shell in 2.0?
The alternative is JunOS-like approach where you get into the normal UNIX shell after login, and issue 'cli' command to enter the JunOS shell.

dmbaturin added a project: VyOS 2.0.x.

Beside Juniper, other router vendor starting with there specific cli shell. But if the JunOS approach is much easier for maintenance on the long term, take this way.

I started using VyOS because I saw Ansible gained support for configuring VyOS devices. I want all my devices in config management. I'd lie if I said I was familiar with the inner workings of the Python module that interacts with VyOS, but from my config management POV I think it makes sense to login into a normal shell and then perform 'some action'. This action could be done in a CLI tool or it could be something OS-related. So for me, I think it makes sense to login to a normal shell first. My two (possibly worthless) cents ;)

syncer added a subscriber: syncer.Dec 31 2016, 3:22 PM

for unix shell better, but it's just because i'm more linux then network guy.
i think MOTD with how to enter into VyOS shell should be enough.

As long as it is simple to get to a system shell, I'd prefer the VyOS shell to be the default

systo added a subscriber: systo.Jan 4 2017, 6:22 AM

I like the separation for admin vs view. Its the same reason we have RO and RW in SNMP v2c etc. While I don't yet have hands-on experience with Junos, I specifically like the demarcation of configuration vs show commands. For those that don't like the dual approach, can't the run prefix be used to enable a flatter CLI approach?

Merijn added a subscriber: Merijn.Jan 4 2017, 10:23 PM

In JunOS the root user enters in the shell and uses 'cli' to enter show mode followed by configure for config mode.
When i add an extra user without shell access, this user is placed directly into show mode.
The vyos user is not the root user, so the way it currently is makes perfect sense to me.

mickvav added a subscriber: mickvav.Jan 9 2017, 8:03 AM

For me the current defaults is fine for router-like device. But it's a good idea to have this option in user config, e.g.

set system login user linuxfan login-shell /bin/bash

I think if you keep in mind the Principle of Least Astonishment, the answer becomes obvious: when you login to VyOS, do you expect a VyOS shell or a Unix shell? VyOS! Conversely, when you login to Unix, do you expect a Unix shell or a VyOS shell? Unix!

FWIW, I definitely prefer JunOS-like (issue command to enter VyOS shell) behavior and agree with the comments about remote configuration, such as with Ansible. This makes mass configuration, change-controls, and backups much more like other *nix based installs. It also makes munging the VyOS command output available out-of-the-box on the VyOS install, i.e. IMO it would be much easier to call VyOS shell sniplets from scripts in bash, tcsh, python, perl, etc, than to deal with getting out of the more captive shell back to a "real" shell for a custom script, cron job, etc.

@jpbostic I think @mickvav has a point here, making it configurable is relatively cheap (it's just a field in /etc/passwd after all, or a call to chsh). People who don't want it to be the deault like myself and service accounts for ansible etc. can just change the default.

jpbostic added a comment.EditedJan 14 2017, 3:30 AM

@dmbaturin @mickvav yes, definitely a very good point, and I'm guessing that same new VyOS shell would then be callable from the changed-to Unix shell (e.g. cli -c "show configuration commands | match blah") ... nice.

dmbaturin added a comment.EditedJan 14 2017, 4:31 AM

@jpbostic My idea for interacting with vyconf from outside the interactive shell is a bit different. The issue with 'vyshell -c "set interfaces ethernet eth0 disable' is that it needs to setup a session first, and store the session ID between commands, so either it will be limited to 'vyshell -c "configure; set interfaces ethernet eth0 address; set interfaces ethernet eth0 mtu 1400"' (i.e. long command strings in single call), or it will be dependent on specific environment setup, and from VyOS 1.x we already know how problematic it will be.

My idea is to make the shell purely interactive, but add a non-interactive CLI client that can a) take session ID as an argument b) use top level words (set/delete/...) as subcommands, as in:

export SESSION=$(vycli setup-session)
vycli --session=$SESSION configure
vycli --session=$SESSION set "interfaces ethernet eth0 address"
vycli --session=$SESSION set "interfaces ethernet eth0 mtu 1400"
vycli --session=$SESSION commit
vycli --session=$SESSION exit
vycli --session=$SESSION teardown-session

It may also try to use SESSION environment variable when --session option is not given, but the point is that either way the session ID is the only thing it needs to operate, as opposed to a whole lot of shell variables and aliases it needs now (run "cli-shell-api getSessionEnv $PPID" to see how much stuff it needs just to setup a session).

yakatz added a subscriber: yakatz.Feb 6 2017, 9:04 PM