Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Cisco Employee

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

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

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Hi WayneUpload the package to

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

60 REPLIES
VIP Purple

Noticed it said that the root

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?

Oh no Cisco - what are you

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

VIP Green

From the Release Notes:Root

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.
Wayne
--
Please remember to rate responses and to mark your question as answered if appropriate.
VIP Purple

Just like everyone else that

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.  :(

VIP Green

While I have no problem with

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.

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

Maybe you can let us know

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

Ok, to beginning with:All

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.

Cisco Employee

It should be noted the

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.  

 

 

Hi Steve,I feel you are wrong

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

 

Cisco Employee

"In fact, it was a breath of

"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.

Oh well. I despair!!!If you

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....

VIP Green

Hi Magnus,Chris' list is

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.

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

Hi WayneUpload the package to

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

WE should have the ability to

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.

New Member

I have been reading this

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

 

VIP Green

Thanks for your reply Magnus

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.

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

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

I'll +1 your comment ;)In

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).

 

+1At the very least, we need

+1

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!!!

VIP Green

Here's another thought -

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.

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

I’ll add my +1 to this as

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.

Think with Portals
Cisco Employee

Hi Chris,When using the web

Hi Chris,

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.

hi Roger,Pleas note that I

hi Roger,

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.

Chris

Cisco Employee

Hi Wayne,If you use the API

Hi Wayne,

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): 

    Username: remotesupport

    Expiry: 2014-05-11 10:15:02 UTC

    Passphrase: (removed)

---

VIP Green

Thanks Roger - is there a way

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?

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

From how I see it you have to

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

VIP Green

Thanks Martin - That's how I

Thanks Martin - That's how I see it too... was hoping there may be another way around it.

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

Hi Wayne,The expiry date is

Hi Wayne,

The expiry date is embedded into the token, so you will have to create a new token.

Roger

Cisco Employee

Hi WayneYou should not

Hi Wayne

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.

/Magnus

Cisco Employee

HiYes I totally understand

Hi

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. 

systemtools network
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".

/Magnus

2074
Views
177
Helpful
60
Replies
CreatePlease to create content