Removed enable, Cisco SMB Switches do not have the enable switch

[bueste]

Pre-Request Checklist

• [x ] Passes rubocop code analysis (try rubocop --auto-correct)
• [x ] Tests added or adapted (try rake test)
• [x ] Changes are reflected in the documentation
• [x ] User-visible changes appended to CHANGELOG.md

Description

Cisco SG Switches do not work because the commands are not right. Removed and tested with Cisco SG250, Cisco SG350 CBS250 with Password Authentification

[bueste]

[ytti]

Documentation seems to suggest enable password is supported:

CBS250 CBS350

What is your interpretation on what the code does? Why do you think it's not working for you with the code in place, and works without the code in place? The code is looking if enable is defined or not, if it is not defined, the code does nothing. Are you passing enable password to a device configured to not need it?

[ytti]

Why is the new model needed, what exactly doesn't work and what does it fix? Duplicating the models is undesirable, if modifying works.

[ytti]

Looking at the new model, which is incorrectly still using the old model Class name, therefore overriding it, instead of defining new class name, so which ever is loaded last, takes precedence.

I tried to identify what you've done with the new model, to understand why you think you need it. But couldn't find any material changes.

1. You change how secret commands are masked, this is not model dependant
2. You break how show version is parsed, by forgetting regexp 0 or more * character for the any character . , this is not model dependant.

I couldn't observe any other changes. I strongly believe.

1. New model is not needed, it doesn't do anything to differentiate the models
2. Old model change is not needed, you just need to stop passing enable password to it

[bueste]

1. The Cisco CBS220 Crashes with the original prompt /^\r?([\w.@()-]+[#>]\s?)$/ I had to change the prompt, so that it work with a cisco CBS220. With the other switches it worked
2. Cisco SG350 and SG250 gave an error in the debugmode and couldn't backup the config. After passing the enable they could successfully backup

[bueste]

Ok. Copy paste error. of corse the new one needs the new modelname :-). My misstake

[bueste]

The

Looking at the new model, which is incorrectly still using the old model Class name, therefore overriding it, instead of defining new class name, so which ever is loaded last, takes precedence.

I tried to identify what you've done with the new model, to understand why you think you need it. But couldn't find any material changes.

1. You change how secret commands are masked, this is not model dependant
2. You break how show version is parsed, by forgetting regexp 0 or more * character for the any character . , this is not model dependant.

I couldn't observe any other changes. I strongly believe.

1. New model is not needed, it doesn't do anything to differentiate the models
2. Old model change is not needed, you just need to stop passing enable password to it

The prompt is diffrent

[ytti]

1. The Cisco CBS220 Crashes with the original prompt /^\r?([\w.@()-]+[#>]\s?)$/ I had to change the prompt, so that it work with a cisco CBS220. With the other switches it worked

Your prompts are identical in both files in your pull request.

2. Cisco SG350 and SG250 gave an error in the debugmode and couldn't backup the config. After passing the enable they could successfully backup

I don't understand this. What are you saying? I think what you are saying is, if you set secret on, you can't restore the device from backups? But this is same in both models, you are not supposed to be able to restore devices if secret is set. If you want to restore the device, you must not set secret.

[ytti]

@davama @Atroskelis could you please look into this?

[ytti]

close the request

I hope you're saying this, because you were able to solve your problem with the old model, instead of saying this, because I misunderstand what you're trying to do.

[sharteeya]

I do have a CiscoSMB devices that have no enable command too. Just don't give it enable variable. For special cases, you can build an edited model in .config/oxidized/model instead of changing the original model.

[davama]

I do have a CiscoSMB devices that have no enable command too. Just don't give it enable variable. For special cases, you can build an edited model in .config/oxidized/model instead of changing the original model.

I agree with this. Tooling already exists to create custom models for special cases. No need to alter default model.

[Atroskelis]

@davama @Atroskelis could you please look into this?

I have various Cisco SG switches, let me know if testing is still needed Cisco CBS is the new variant of the SMB switches, a new model would seem suitable as i dont know how much linksys they still have in their CLI.

[ytti]

@davama @Atroskelis would either of you, like to adopt this model or more models? We've recently introduced in the models document maintainer for models.

0 commitment, but basically approve/suggest changes on pull requests for those models, and generally tend to them as you see fit.

Anyone can claim ownership on any model, and of course can remove themselves as maintainers if they no longer have cycles for it.

[davama]

@ytti

If we are talking about this new ciscocbs model, i dont have hardware to validate/test with it. So dont think im a good candidate.

Are we saying that we are approving the PR in its current state, since ciscosmb was changed?

[ytti]

If we are talking about this new ciscocbs model, i dont have hardware to validate/test with it. So dont think im a good candidate.

Any model at all, really. So there is someone people can '@maintainer' to comment on changes to that model.

Are we saying that we are approving the PR in its current state, since ciscosmb was changed?

@bueste is requesting closure, but I'm worried if it's because it's not needed or if I misunderstood the need.

[davama]

Any model at all, really. So there is someone people can '@maintainer' to comment on changes to that model.

I see, i dont mind being a "maintainer/reviewer" for some of these models.

[ytti]

Any model at all, really. So there is someone people can '@maintainer' to comment on changes to that model.

I see, i dont mind being a "maintainer/reviewer" for some of these models.

Just pull request the model doc, and add yourself, thanks.

[robertcheramy]

The Rubocop warnings were in PR #3074, not #3047. Sorry for this.

[davama]

My two cents on this pr

the title of the pr does not reflect the commits.

yes, we see the removal of enable but we also see the addition of a new model.

im of the opinion that this new mode should be a separate pr