This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Is it possible to show the FQDN in the "DNS name" field Vmware summary page? Usualy this field shows "hostname" which is pulled by vm tools. For example this configuration of ISE:
ip domain-name local.host.
Vmware shows "test", but I need to see the FQDN - "test.local.host"
Solved! Go to Solution.
If you had root access then you can see the FQDN in /etc/resolv.conf
It irks me every time I want to do something simple like this and this product treats me like a baby. In my opinion, half the Noddy TAC cases in the world would disappear if we had access to the Linux shell. We don't live in 1998 any more.
I actually tried it and it would not accept the periods.
@Arnie - there are a few reasons we do not provide root access. Primary reason to to secure access to system and only offer access needed to perform admin functions. As you may have seen, many new options have been added to the CLI shell that were previously restricted to root access. Exposing root would greatly increase the risk of this appliance with core functions around security.
Craig, I think restricting root access keeps people from breaking themselves, but the security argument is a little bit odd because Firepower/FTD are as much a security appliance as anything else and they allow root access to customers.
Just an observation .
Is that really a good thing? Access to login and make changes to core OS system files is generally more risk than benefit. Certainly the perspective from posts here are coming from more savvy persons with goal of serviceability and not compromise, but ultimately need to take in all potential users / requirements. If specific access limiting ability to service system, then please detail those out so we can look to address gaps. I don't think wide open access is the answer. I also cannot answer for other product teams. I suppose there are other products on market that are branded as security devices but offer little security or protections. I certainly would not call that a better solution.
Realize if there were issues impacting system, one of the basic tenets is that we should not need to scrub entire system for custom changes or compromise that would impact system functioning. Secure Boot was specifically mandated to avoid custom changes to the system for stability, availability, and security purposes.
If ISE ran reliably then I would agree with Craig - no need to look under the hood every 5 minutes. But my experience is quite the opposite. Last night I could not reboot an ISE appliance (reliably) because the backup was stuck and was preventing it. When we forced the reload in the past the end result was a catastrophe. What this now requires is a TAC case, installing root application, and then killing the offending process. And this is routine stuff we're talking about - I don't take pleasure in looking under the hood of this thing.
This product is put in the hands of IT professionals and taking away root is like putting the padlock on your car's hood - sure, if you buy a reliable automobile then you don't need to look under the hood. I would argue that taking root access away from a consumer grade product like an iPhone or Echo makes more sense because you don't know who you're dealing with.
Cisco could deliver a half decent CLI access in ISE, through a non-root user - at least we can tail files and do non-destructive things. Most of the time all we need is information (logs, process, netstat, tcpdump etc) - any tools like netstat can be "root enabled" using sudo groups, or pcap (very powerful) and/or SELINUX.