Issue-419 fix

[charlesklement]

In order to solve the TMOS issue of externally authenticated users not being placed in the bash shell automatically, I've made some adjustments to tmos.rb. I've tested these against a system running tmos 12.x with a local account and also with an external account. I don't have access to an 11.x system for testing.

• disable "exec true" . Otherwise post_login and pre_logout are not processed.
• create a prompt string. The prompt as defined should match either a bash shell or a tmsh shell

[mikebryant]

@benbacardi I think you'll have an opinion on this for our 11.x series devices

[ytti]

I really really wouldn't want to get rid of exec. Walk me again why it's not practical to change the config backup users shell?

[charlesklement]

externally defined users (radius / tacacs / ldap ) are not able to have bash defined as a shell. here's a link to an F5 kb. https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10272.html. At least in version 12.x if I try to create a user locally in the UI, (while also having external users) it won't allow me to set a password.

I attempted to create a local user with the same name as an external user, but the end result is that logins fail if I attempt that.

It looks like the exec channel is only used in a couple of model types. Is there a discussion you can point me to that outlines why we should try and avoid the shell?

[ytti]

That is good justification.

Exec never requires any screen-scraping. It does this

output1 == start_exec_channel(command1)
output2 == start_exec_channel(command2)

Unlike without exec, where we have no idea where output for command starts and end, we try to look for a prompt and use it to determine. That is dirty and fragile. Exec is robust.

One thing we might be able to do. Can we, from normal shell execute bash commands with some prepended command? Like cmd 'run_shell actual_command_here' do |output|

[charlesklement]

unfortunately I can't find a way to call bash commands from within tmsh.

I think that I can probably replicate most or all of the commands using show commands within tmsh. If so, perhaps we could consider adding a second model type for those of us stuck with tmsh. Alternatively, if I can replicate all of the commands, then make that the default and people using local accounts can select tmsh instead of "advanced shell" (aka bash)

Do either of these sound preferable to not staying in exec?

[ytti]

So /run util bash does not take arguments?

I'm afraid it may be best bet to stop using exec unless @mikebryant has some thoughts.

[charlesklement]

Actually, I was completely wrong. There does seem to be a way to call subcommands.

here’s an example.

rancid@(lb1a)(cfg-sync In Sync)(Standby)(/Common)(tmos)# /run util bash -c 'tmsh -q show sys software'

---

Sys::Software Status

Volume Product Version Build Active Status

HD1.1 BIG-IP 12.0.0 1.0.628 no complete HD1.2 BIG-IP 12.0.0 2.0.644 yes complete

I was fooled when I tried to pass arguments without the ‘-c’.

On Jun 1, 2016, at 2:49 AM, ytti [email protected] wrote:

So /run util bash does not take arguments?

I'm afraid it may be best bet to stop using exec unless @mikebryant https://github.com/mikebryant has some thoughts.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ytti/oxidized/pull/443#issuecomment-222945207, or mute the thread https://github.com/notifications/unsubscribe/AK8xfca4JUU_4vKf9gaq4IFWnmXdT8Mfks5qHVWVgaJpZM4In15l.

[ytti]

I'm not proposing this, just thinking aloud. We could have

vars:
  tmos_shell: true

Then in model:

def tmos_cmd string
  vars(:tmos_shell) ? "/run util bash -c '#{string}'" : string
end


cfg :ssh do
  if vars(:tmos_shell)
    pre_login do
         ...
    end
    post_login do
        ..
    end
  end
end

cmd tmos_cmd("actual command string") do |cfg|
    comment cfg
end

Dunno if this is too complex/confusing, and if we should just ditch exec. I wanna hear @mikebryant chime in.

[danilopopeye]

Maybe another model TmosWithBash that implement #cmd with the shell options?

class TmosWithBash < Tmos
  def cmd(command)
    super("/run util bash -c '#{command}'")
  end
end

(not sure this will work, just to express my idea)

[ytti]

Yeah that would work too. We can do new model, we can do variable based branching. Or we can just do shell for everyone and forget exec.

I'm on the fance, doing shell for everyone is least complex, and thus least likely to be buggy. But if someone MUST use exec for one reason or another, there is no avoiding the added complexity of two approaches. We'll really need input from someone using the exec mode.

[laf]

@mikebryant @benbacardi do you have any opinions on what approach to take for this?

[benbacardi]

I feel it would probably be best as a new model. It'd be a shame to lose exec, and it seems like the solution is slightly less complex with a new model rather than variable based branching.

[mortzu]

any news on this?