TC7.1 is now released and available on Cisco.com

[Magnus Ohm]

I am pleased to announce that TC7.1.0 is released and can be downloaded on http://www.cisco.com.

Please read the release notes:
http://www.cisco.com/en/US/docs/telepresence/endpoint/software/tc7/release_notes/tc-software-release-notes-tc7.pdf

Regards,
Magnus Ohm

[Patrick Sparkman]

Noticed it said that the root account is now disabled, and there is a new account for support, but is only available via opening a TAC case.  How can we gather tcpdump files, reload a config file, etc that we would typically do via root - I presume it's through the new account via TAC?

[Chris Swinney]

Oh no Cisco - what are you doing to us???

I am away from the office this week but if what Patrick says is true, its not good! Can we simply order multiple TAC cases on all our endpoints to get root back?

Chris

[Wayne DeNardi]

From the Release Notes:

Root account is permanently disabled

Cisco has decided to disable the root account completely for security reasons. A new restricted user"remotesupport" can be created on the endpoint. This user has read-access to the system and a limited set of commands that can aid troubleshooting. The user can be created from the System Recovery section -> Remote Support User in the web interface.

Once the user is created a token will be presented. To decode the token and acquire the password a Technical Assistance Center (TAC) case must be opened. The remote support user should only be enabled for troubleshooting reasons when instructed by the Cisco TAC.

So, looks like we'll have to log 100s of TAC cases with the 100s of Tokens we'll have to get from each of our devices individually so we can support them properly - this sounds pretty dumb to me. (Unless the new "remotesupport" user can "sudo" to have root access (or similar).

Especially since the WinSCP upgrade (which uses the "root" account) was one of the most reliable ways to update the software on an endpoint (especially when other means failed).

I'd really like them to re-think this one!

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[Patrick Sparkman]

Just like everyone else that supports video endpoints, that disabling the root account is a bad idea in my view as well.  The moment I saw this mentioned in the release notes, I was like, what is Cisco thinking!?  I hope they do think this change over again.

A better explanation on the "remotesupport" account would be good.  Maybe it's just a stripped down root account?  Although like Wayne said, if you have a lot of codecs, activating this account and getting the passwords will be a pain in the butt, and all those passwords being different too, hope someone keeps a log of them all.  :(

[Wayne DeNardi]

While I have no problem with the "root" account being disabled for security purposes - we need another way to access all the tools, troubleshooting and upgrade methods previously utilised with the "root" account.

So, I upgraded one of my devices to have a look - the "remotesupport" user that can be enabled has an expiry date and is only valid for 7 days!!!!!

There goes the thought of requesting activation of the accounts across the whole fleet.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[Magnus Ohm]

Maybe you can let us know what specific tools you need access to and why you need it. Some are already available without utilizing remotesupport user or root.

/Magnus

[Chris Swinney]

Ok, to beginning with:

1. All trace... and Ping options available to root, including using TCP and UDP possibilities rather than just ICMP
2. TCPDUMP - all options. Obviously with the ability to save dumps
3. WinSCP access to file system to retrieve and upload config info and logs (such as above, and others)
4. ifconfig and Ethernet utilities.
5. er, any and all other root type Linux commands that are available within the build

These are complex devices in complex environments managed by technically able people. You are (in my opinion) severally diminishing our ability to manage and maintain our OWN BOUGHT equipment. Should we be unable to figure out a particular issue, then sure TAC can get involved, but we don't want to keep going cap in hand back to Cisco because YOU have limited us to complete our jobs.The web interface is simply not enough.

This is a bad decision, plain an simple.

[Steve Kapinos]

It should be noted the remotesupport path is exactly what has been used for CUCM and Cisco's other 'blackbox' OS deployments for some time.  This is an established methodology.

As for 'bought equipment' - the OS was never part of the advertised feature set, nor supported interfaces.  The OS was always intended to be obscured from the customer and not part of the normal use of the system.

Having supported endpoints and solutions since the days of the GPT codecs - I find the endpoint's built in diagnostics for networking better than ever - and that doesn't include going to root.  Honestly I never find myself using root in the codec for normal troubleshooting... and lack of root on the MXP systems did not hinder my abilities to build and troubleshoot networks.  

[Chris Swinney]

Hi Steve,

I feel you are wrong, and with one of the largest deployments of MXP devices across Europe (if not the largest), we find it far more invaluable to gain root access to C series CODEC rather than MXPs. In fact, it was a breath of fresh air when Tandberg released the C series CODECs and that we finally had the tool that we needed to fault find properly.

Cheers

Chris

[Steve Kapinos]

"In fact, it was a breath of fresh air when Tandberg released the C series CODECs and that we finally had the tool that we needed to fault find properly"

That is what I'm reading in your posts.  You saw the OS of the C-Series endpoints as a new tool in your toolbox.  It was always intended to be a 'blackbox' and not have end-users or partners using the OS as a new toolset.  It has been used through the years as a means to service units beyond the application shell, but was not ever intended to be a general purpose computer and as the software has matured, the need to resort to the shell to service the unit is dwindling.  But now you have come to expect it to be available.  The blocking of OS access in the unit has been slowly phasing in since TC4

If I want to troubleshoot the network, I use my networking tools and utilities.  The OS access to the C-Series has always been a backdoor of convenience at best.. not a feature of the product.

[Chris Swinney]

Oh well. I despair!!!

If you give us what we currently use and now need rather than just remove functionality (however it has come to be) willy nilly, then expect a backlash. Until you can give us the full equivalent of all the options we have now, don't think that we are going to be happy.

One of the BEST tools to diagnose network issue ARE the network tools built into the OS on a device that is directly involved in a traffic flow. What an earth to you think the Linux OS was built around?????

Once again - I DESPAIR....

[Wayne DeNardi]

Hi Magnus,

Chris' list is pretty much what we need here too.

And WinSCP uploading of the firmware - you mentioned this was possible, but when I tried it, I could not upload the "pkg" file to the /upgrade folder, and only to the /upgrade/upload folder which then doesn't actually kick the upgrade off - is there a new set of instructions to do a WinSCP upgrade with TC7.1?  (I was using the previous instructions in documents section).

I was able to run most of the commands logged in as "remotesupport" using the "sudo" command, so can use this as a workaround for the 7 days I have access.

While I have no issue with "root" being disabled for "security reasons" - we do need to have ways of performing the same troubleshooting functions we currently use - ideally, via a non-expiring account, to save unnecessarily contacting the TAC and to save time (took ~30 minutes yesterday to get a password for "remotesupport").

Edit: I've just logged a bug (CSCuo18246) for TC7.1 with the output of the ifconfig command.

Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.

[Magnus Ohm · Accepted solution]

Hi Wayne

Upload the package to the /tmp folder (remotesupport has write access here) and log in as the remotesupport user.

Then run the command: sudo installimage <package name>

It´s not automatically triggered. We might increase the active duration for the remotesupport user in a later release.

1. All trace... and Ping options available to root, including using TCP and UDP possibilities rather than just ICMP

If you need additional options (or all the options) using ping for a specific scenario then you can activate the remotesupport user by contacting TAC. It would be nice to know what kind of options that you specifically need and why you need it in the xAPI. Example scenario? Is this something many are using, often? Those factors can be used to push devs to include the functionality in a future release. 

1. TCPDUMP - all options. Obviously with the ability to save dumps

TCPDUMP is available from the webinterface and from the xAPI. The command options are fixed but you have two choices, LIMITED and FULL. If you need access to TCPDUMP when the webinterface is down and no access to the tshell, then contact TAC to open the remotesupport user.

Full tcpdump is equal to this command with the following options:

”tcpdump  -B 4096 -n -nn -w /tmp/extendedlogging.pcap”

Captures everything, (fixed 3 minutes duration, custom duration not supported)

Limited: ”tcpdump not ( udp and portrange 16384-32766 ) -B 4096 -n -nn -w /tmp/extendedlogging.pcap”

Limited: Tries to avoid capturing media, (max 10 minutes duration, can be customized in xAPI but not from web)

The dump file is saved to the /tmp folder and can be directly downloaded from the webinterface of the codec or with the remotesupport user if necessary.

If you need longer durations you can setup a pipe in order to do a remote capture without duration limitation. (requires remotesupport user).

1. WinSCP access to file system to retrieve and upload config info and logs (such as above, and others)

You can retrieve the logs from the webinterface or WINScp using the remotesupport user. Most of the time it is sufficient enough to go to the web to do this. The config file can be downloaded and restored from the webinterface Maintenance --> Backup and Restore.

1. ifconfig and Ethernet utilities.

Ifconfig for both the codec and the touchpanel can be seen and refreshed on the touch panel it self. The ifconfig command is also available from xAPI. If you need more options on the ifconfig what specifically would that be and in what troubleshooting scenario is it useful? What other specific Ethernet tools are you talking about here? 

1. er, any and all other root type Linux commands that are available within the build

You can use most of the relevant commands as the remotesupport user, but the user needs to be activated first. So what really is the downside here is the amount of time it takes to get the token decoded by TAC? Is that it? Thanks for all your feedback on this.

/Magnus

[Chris Swinney]

WE should have the ability to gain access to these prompt - full stop. WE should NOT need to get TAC involved as this stage.

You guys are further alienating customers that have been loyal to these products for years. I have not idea what you hope to achieve by this move other than to loose revenue.