I have been reading this thread with some interest.
We have 750 endpoints and in response to the Heartbleed vulnerability we upgraded ALL our systems that run TC software to TC7.1.1 (350+)
I do not miss the root access... did not use it much and we got hit with a security vulnerability when there was a default password on the root account detected
I like the ability to do a fast and simple packet capture from the web interface
The call history now included the network performance during the call - nice
for example... we had issues with the NTP clock sync and earlier software I had to enable root access, then SSH in then type the correct comand
Now, I can see the NTP status in the web.
We are mostly telecom folks with limited experience in Linux command line interface... as indicated before, its an appliance, I'm not buying a Linux server
just my .02
Thanks for your reply Magnus.
Your fix for the WinSCP upgrade with the "remotesupport" user worked. Thanks for that. Although this still requires having that user activated and knowing the password which I can foresee may not be available under certain, but rare, conditions. We often use the WinSCP upgrade method on some of our remote sites that are not easily accessible (they're an 8 hour drive away) and only have a slow or unreliable network connections - uploading the firmware via WinSCP has been found much more reliable and stable than via http(s) in these circumstances.
ifconfig: If there is no touch panel attached, and with integrator codecs often not in the same room as the display panel, it is a useful tool from a command line. The results from ifconfg seem to be inconsitent too (see bug CSCuo18246).
ping: being able to do both an IPv4 and IPv6 ping can be useful. Being able to do a continuous ping can also be very handy. Specifying packet size has been helpful finding issues with MTU sizes on a number of externally operated sites in our environment.
tcpdump: it's often helpful to be able to specify a more complete command line to limit the capture and reduce the amount of irrelevant information in the initial capture file. This makes it easier to sift through rather than further filtering the information in another tool.
Other than that, the requirement to contact the TAC, and the additional time it takes to then get the password for the account, and only having it available for 7 days is my major complaint at the moment. The rest of my issues I can work around with the options you've described, or using sudo from an enabled remotesupport account. But having this (or another) account available on a more permanent basis would allow troubleshooting of a device at the time it is required - this is critical in a large, complex, environment. And especially where the other network management/monitoring tools are not available to the "TelePresence" people, only the "Network" people who don't want to believe there is anything incorrect in their environment.
Please remember to rate responses and to mark your question as answered if appropriate.
I'll +1 your comment ;)
In order to be an effective video conferencing engineer you MUST be at the very least an adequate network engineer. There just no getting around it.
CISCO believes differently than Tandberg did it seems. Let's not forget that old Codian products seem to be NetBSD based (based on the licensing in the docs) and there is NO root access to those products (like the 8510).
Having root access definitely allows those people with the know how to troubleshoot things quicker, and with less TAC involvement. (that's good for us, I guess TAC would like to know).
At the very least, we need an set of features on endpoint relevant to an IOS system. Oh hang on a minute, under root on the current build we have!!!
Here's another thought - perhaps, rather than requesting the password from the token by logging a TAC case - could we request it ourselves through the www.cisco.com/go/licence portal? That'd make things at least one step easier/quicker.
I’ll add my +1 to this as well, I think this is an excellent idea, as my personal concern is that if we need to engage TAC this can add a delay to a solution which we may be able to find quicker, after all supporting end users is all about the speed of response and solution.
I like this idea.
When using the web to download the logs you get additional information such as the configuration and status of the system. This is very valuable for troubleshooting. In addition to this you also have the option to include the call history which will include packet loss history. So for downloading logs, the Web Interface is a better option than WinSCP.
Simple ping and traceroute is available from the 'systemtools network' command as well as ifconfig. This command is available without root or remotesupport account.
Pleas note that I did not say simple Ping and traceroute, BUT ALL trace... (including route and path) and other ping options that are NOT available on the web interface. These are ESSENTIAL for troubleshooting including using multiple protocols and options to figure out routes and paths.
The are obviously other root function that are useful, so in my opinion your post offers me nothing.
If you use the API to generate the remotesupport account you can set the expiry for up to 31 days:
xcommand UserManagement RemoteSupportUser Create ExpiryDays: 31
*r UserCreate (status=OK):
Expiry: 2014-05-11 10:15:02 UTC
Thanks Roger - is there a way to extend the expiry on an existing account, or will I need to re-create and request a new password/token?
From how I see it you have to delete the remotesupport user and by that
you loose access, so no chance to "renew" before "expire", ...
Please remember to rate helpful responses and identify
Thanks Martin - That's how I see it too... was hoping there may be another way around it.
You should not commonly need to activate the remotesupport user. You can do winSCP upgrade with the remotesupport user and yes it has sudo access for some commands that require this but to aquire access to the user is quite cumbersome. You would now have to use the alternative ways to upgrade the system: Web interface, xAPI, TMS, CUCM.
Yes I totally understand your reactions here but unfortunately we had to disable root but at the same time we tried to make available most of the troubleshooting elements that are commonly used as root. This of course includes TCPDUMP. You can now do TCPDUMP from the webinterface of the codec and as admin from xAPI. The deleting of config.db is no longer an option to do a reset but again there are 4-5 different ways to factory reset the system without utilizing root.
xCommand Logging ExtendedLogging Start PacketDump: Full
The packetdump will be stored in the /tmp folder as "extendedlogging.pcap" and this will show up in the webinterface for direct download.
From web you can do this from Diagnostics --> Log Files, there is a "start extended logging" button there with a dropdown, here you can select to include a packetdump.
The new remotesupport user is not a root account, it has read access to the system and can execute a selection of commands with troubleshooting relevance. It is part of the sudoers list so it can run TCPDUMP but this should not be necessary anymore as TCPDUMP is available in the webinterface and from the xAPI.
From the xAPI you also have access to various network tools.
usage: network ping <hostname> | traceroute <hostname> | netstat | addrs | ifconfig
If you are missing anything that you where able to do with root please let me know and we can see if there is something else that can be included. If there is a real need for it...
The remotesupport user should really not be needed to perform most of the troubleshooting actions on the system. It´s there as a "last resort".