Is it possible to delete the idp signature database from a branch-level SRX (preferably not a factory-reset)? I ran a trial license and now I want to reclaim the space so that I can fit a full Junos package onto one of the partitions. License is deleted already, but the DB is still present.
super@SRX> request security idp security-package ?
download Download security package (Package includes detector and deltas for attack table)
install Update attack database, active policy, detector with new package
super@SRX> show system storage
Filesystem Size Used Avail Capacity Mounted on
/dev/bo0s3f 342M 126M 189M 40% /cf/var
root@SRX% du -sh /cf/var/db/
Version is 10.4
Its possible, what stops you from just deleting those files?
root@srxA-2% du -sh /var/db/idpd/ 76M /var/db/idpd/root@srxA-2% du -sh /var/db/idpd/sec-download/ 21M /var/db/idpd/sec-download/root@srxA-2% du -sh /var/db/idpd/db/ 48M /var/db/idpd/db/
I had the same problem once (lack of free space on flash due to idp database) and
I moved largest files from those directories to my PC (via WinSCP) then upgraded JunOS
and returned them back. It was working. Not the best way to upgrade of course.
But you can delete the files, this should not be the problem.
I figured that would be possible, but I'm not sure if just deleting the files via the shell cleans up all references to the files. I would think that the option should be available via the CLI (probably using some 'request' command). If that is not the case, I would think that there would at least be some KB article or documentation on how to 'manually' go about deleting the files and any references to them.
Agree... By the way, they have that option for UTM, e.g.
request security utm anti-virus juniper-express-engine pattern-delete
Looks like if you want to delete IDP database in a supported way, you
have to go with "request system zeroize".
I had a database corruption earlier on this year. I contacted JTAC and was sent instructions on how to delete the database.
If you follow the instructions to stop the IDP process and then delete the IDP database, it should help.
How to recover from database failures for IDP:
Disable idpd process from the configuration
root@router# set system processes idp-policy disable root@router# commit
Once the idpd process is disabled, go to initialize (prune current records).
secdb failures, execute the following:
root@router% rm /var/db/idpd/db/secdb* /var/db/idpd/db/rdm.taf
Now reboot the device (it will initialize the secdb database) root@router% cli root@router> request system reboot
RE attack cache (DFA/PCRE cache) failures, execute the following:
Once the idpd process is disabled, we can go ahead to prune the database records
root@router# rm /var/db/idpd/db/dfa* /var/db/idpd/db/pcre* root@router# rm /var/db/idpd/db/cache.dbd /var/db/idpd/db/rdm.taf
Now reboot the device (it will initialize the cache database) root@router# cli root@router> request system reboot
Note: For RE attack cache, users need not do anything (the cache will build-up on subsequent policy compilation(s)).
After the device reboots, enable idpd process root@router% cli root@router> edit root@router# delete system processes idp-policy oot@router# commit
Now download the full-update of the security package and install it
root@router> request security idp security-package download full-update root@router> request security idp security-package download status
Once the download is complete, install it:
root@router> request security idp security-package install root@router> request security idp security-package install status
The device is recovered from secdb failure.
The newer fimrware images have a smaller foot print and freee up storage space.
+1 To johnrbaker - I hit this problem recently trying to upgrade from 10.0R3.1 running IDP - there was only 120MB of flash available. Fortunately I stumbled onto this post at the JSRX Wiki:
To summarise, just delete everything in the idp database, then add your new image and reboot:
bdale@srx> start shell
bdale@srx% cd /var/db/idpd/db/
bdale@srx% rm -rfv *
Glad to see that there is a 'sanctioned' removal method. Hopefully, this process will become a little more elegant in a future release.
@pk & dfex: thanks for your input as well.