SMC Stuck in Initializing 7.5.0 (root denied, no way to TSHOOT)

[DanielLarsson63527]

Hi,

Just asking to see if there is anything to do with SMC stuck in initializing after power-failure?

Seems 100 year backwards to lock troubleshooting out for customers and engineers behind a TAC-challenge. I should never have upgraded to 7.5.x i knew that would bite me somehow.

Either case, you cannot even access any logs at all without TAC...this *has to be fixed it's not a feature, it's a broken design*

Yes, i can TAC it and hope that they open my case for the day i am available to look at it...not to mention all of our customers facing the same problems with later patches of cisco-products, general recommendation is to just not upgrade if you want to be able to fix issues.

Any tips are appreciated, if TAC is the *only* option available to access logs in 7.5.x SNA then this product is not sell-able.

(yes, i am just as annoyed as all my customers with this approach because almost EVERY SNA install requires root/cli access several times a month)

Thanks,
Daniel

[jamegill]

I missed it in your question, perhaps, but what logs exactly are you trying to get access to?
--jg

[DanielLarsson63527]

Hi @jamegill ,

Thanks for your reply. It doesn't really matter since you cannot get acess to the shell anymore so it is impossible to troubleshoot or do any kind of log collecting...it's all hidden behind a "contact cisco TAC support to use this menu" and  then you have to paste the challenge response. (very very bad design, terrible!)

you cannot even download the diagnostics pack any more or do any sort of troubleshooting. (ISE, DNAC has passed this terrible design decision as well and now unfortunately SNA).

 I get that it might be a reason why locking out people from full root-cli-access etc, but to block skilled engineers and partners from troubleshooting is just outrageous.

This would have probably been a 5 minute fix if i coulc tail som logs or check which services are restarting...or even restart services and see what happens, but no....it's locked for absolutely no logical reason at all.

-Daniel

[jamegill]

Hey @DanielLarsson63527 - I totally get the frustration (having dealt with it several times myself). It requires an added step now, but it is not impossible to get root access.  Contact TAC and get a chalelnge response. This does two things:

1. It allows all deployments an added level of security.  In the short term this will occasionally frustrate us both.

2. It allows support to track reasons why root access may be needed and what causes it in the first place, so that these issues can be designed out.  (Is it the DNS? NTP? DB? Inodes? WTF?)

Finally, in the case where the system comes up to a level where the appliance webUI is accessible, many of the logs can be reached that way.   As someone who is used to being `uid 0` I hear you, but the difference between difficult and impossible is where reality camps.

See you in /var/log,

--jg

[DanielLarsson63527]

Hi @jamegill ,

1. No it doesn't add a single layer of security at all. It only creates a frustration case with end-users and customers. It's a terrible design-decision and there is no way of defending it at all. TAC should be for when you actually need help, but should *NEVER EVER* be enforced with the argument of "added security".

Even if the product worked perfectly fine (which stealthwatch actually never has, it's not a stable product per say) it's *NEVER EVER* a good choice to lock out engineers from troubleshooting it. It's just a lazy fix for not making a proper shell with restricted access, if the argument was about restricting users from messing with the product stability while troubleshooting.

The way pretty much every partner, engineer and customer sees this is that *THERE IS NOT ROOT ACCESS*.

2. Again, just an excuse because anyone with a little bit of linux knowledge would be able to figure that out in a few minutes (and i have every single time fixed these issues without a TAC by tailing various processes and logs, as any reasonable educated engineer would always do before even considering openin a TAC).

3. Now this is the point isn't it, if SNA crashes before GUI is up and there is no way to grab any kind of logs (but funny enough you can still genereate diagnostics packs) and no way of troubleshooting.

Don't make assumptions that partners and customers don't want to troubleshoot basic things as part of normal operations, it's bad design and no argument around it.

Edit: Not that it really matters but as a former CLN VIP, I will say this... facts are... This new approach in many Cisco-products are making them less and less likeable and sell-able. This is feedback from my entire team and every customer (gold partner) when mentioned for products that have done this. Logs should *always, always* be reachable with or without support. Recommendations is to keep all customers on 7.4.x line and stick with it.

-Daniel