kascelemon.blogg.se

1. #Cisco ise 2.4 promote secondary to primary install
2. #Cisco ise 2.4 promote secondary to primary archive
3. #Cisco ise 2.4 promote secondary to primary Patch
4. #Cisco ise 2.4 promote secondary to primary full
5. #Cisco ise 2.4 promote secondary to primary software

Thanks for your time over WebEx, below is the summary : I don’t think so, my best guess is, that they have some sort of rotation in those patches, as there is a hint in the filename which would indicate that this only works this month: Jul-RootKey-appbundle-1.0-x86_64.tar.gzĪfter the TAC Engineer had access to the root shell, the Engineer checked the source of the disk space usage, which eventually bought her to the conclusion that the partition was filled up with „normal“ database data and there is no way to gain any more disk space by purging or deleting. So can I uses those files from now on to access the root shell on any deployment forever? It does not seem like a hardcoded password, you actually set the password, which you’ll, later on, use to log in the root shell. I assume you can set whatever password you want to access the root shell after you applied the patched.

#Cisco ise 2.4 promote secondary to primary install

HKVISE-02/alpiq# application install RootPatch-appbundle-1.4.SSA_NOT_FOR_RELEASE.x86_64.tar.gz hkvbackup-01 % NOT_FOR_RELEASE bundle needed within the next 4 hours. % Therefore the RootKey bundle is temporary and will remove

#Cisco ise 2.4 promote secondary to primary software

% software is installed the RootKey bundle is no longer needed.

% needed to verify the image signature of NOT_FOR_RELEASE % Notice: This RootKey bundle is used to install public keys that are HKVISE-02/alpiq# application install Jul-RootKey-appbundle-1.0-x86_64.tar.gz hkvbackup-01 Saved the ADE-OS running configuration to startup successfully Save the current ADE-OS running configuration? (yes/no) ? yes Applying the Root Patch: HKVISE-02/alpiq# application install RootPatch-appbundle-1.4.SSA_NOT_FOR_RELEASE.x86_64.tar.gz hkvbackup-01 Since she connected to the ISE VM with my PC, I was able to capture the root shell login process. These are the files: 1 samuelheinrich staff 5.1K Jul 19 10:58 1 samuelheinrich staff 10K Jul 19 10:58 RootPatch-appbundle-1.4.SSA_NOT_FOR_RELEASE.x86_64.tar.gz She sent me two files, which I had to install on a repository, which she used to activate the root shell. The TAC engineer responded quickly and we arrange a Webex Session so that he was able to dig into this issue on a root shell level. There might be a way by booting the VM with a Linux CD and mounting the filesystem, but that is clearly out of scope if you are working on a live system in a productive environment. Unfortunately not, during my research, I realized that there is no way to access the underlying filesystem without TAC. So the next thought was to expand the disk space since we are talking about a Virtual Machine this should be pretty easy, huh?

#Cisco ise 2.4 promote secondary to primary Patch

*****************************************įilesystem Size Used Avail Use% Mounted onĪfter doing some research and deleting every logfile, purging every database, cleaning up every patch file in the filesystem I was able to lower the size to 74%, still not enough to get the backup job to work again.

Secondary VM was fine but fine with (60%).

#Cisco ise 2.4 promote secondary to primary full

#Cisco ise 2.4 promote secondary to primary archive

It doesn’t matter if you do a backup to a FTP server or use the internal ISE storage, since the ISE Server always creates a local archive file first, using the /opt disk, before uploading it to an external server. It seems that there is a threshold ( >70%) for the opt partition which prevents the ISE from taking backups. Today I encountered a problem that the backup of a Cisco ISE VM (primary/standby deployment) wasn’t working anymore because of the /opt partition run full of disk space.