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 ;)

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

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?

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.

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.

@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.

@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 192.0.2.1/24; 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 192.0.2.1/24"
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).

Merijn is right in my experience. I think root should get unix and the rest the vyos-cli. If you make it a configurable setting within the vyos-cli it would be bestest for everyone.

I'm all about compatibility with existing behaviour. Looking back over just about every network device I've ever operated, and the bits that annoy me the most is when behaviour is changed in a surprising fashion. I know there's a tension with the ability to actually continue to improve the product, but where there's a choice between 'make it unsurprising', or 'make it cooler', from a user perspective, you want the developers to have exhausted every option to do bother before making it surprising.

Bear in mind that most people are upgrading their infrastructure under duress - they don't WANT the new hotness, they just want the devices to go on doing their jobs, just with modern security fixes, etc. Under those circumstances, any change in behaviour is bad.

And it's not like a real shell is far away should you want it.

Unless there is a specific advantage to changing the behavior of VyOS the existing behavior should be kept. What is the advantage of going having the linux shell be the default? Also, I like the idea of making it configurable.

I'd also greatly prefer unchanged default behavior, but a config option to bring in the new hotness :)

Hey all,

First timer here so apologies for throwing my opinions around!

I would expect to see a shell specific to your NOS after logging in e.g. the VyOS shell for VyOS, IOS Shell for Cisco etc.
I feel that changing this funtionality would mean existing projects with support for vyOS could stop working such as config backup software meaning additional work for their maintainers.

I don't see any advantage to changing functionality at this time and I like how the shell currently functions, but as the world continues to move towards automation the ability to configure this on a per user basis via the cli seems like a good course of action as it would allow you to setup a shell user and then continue your automation tasks via shell.

Thanks :)

First logging into a normal OS shell probably would help with third party tools (like ZeroTier and JumpCloud that I requested as features).

Changing "default behavior" on a new major version is OK for me, following the SemVer rationale that major versions are defined by "breaking" with previous concepts.

I like the way it works now, but honestly as long as I can get to both the CLI and the OS shell somehow (with a command), I don't really care which is the default.