Accidental Upgrades

[Steve_Fuller]

If upgrade paths are so important (and I believe they are), why does the upgrade screen default to the latest version and not the next step in the path?  Or if they can't do that, just add an "Are you sure?" prompt?

[Steve_Fuller]

Fantastic! Thanks for the info!

[seadave]

Thanks Jordan.  Great info.  Firmware updates are always tricky.  A billion different configurations and hundreds of hardware platforms.  Considering the pain and suffering experienced in the 4.0 to 4.3 days and even 5.0, I think we are currently living in a good time.  As many have mentioned, the same rules remain:

1. Read the release notes and understand BEFORE you update.

2. Be skeptical of anything that is .0 or .1.  Watch the forums and let someone else test the water first if you can't afford to be a beta tester.  Never install an update the day it is released unless you have a critical flaw to patch.  Wait a few weeks, just to be safe.

3. Have a copy of both your current and new firmware saved on a PC that you can access the FG with, in-case you need to roll back.

4. Have a TFTP Client, PuTTY, serial, and ethernet cable handy for a worst case scenario (a long time ago I pushed a corrupt firmware image to a FG and having these setup saved me lots of time).  Also if you haven't pushed firmware via TFTP before, download the tech article http://kb.fortinet.com/kb/viewContent.do?externalId=10338

5. Always have a backup of your current config right before update (FOS will now force you to do so) and also create a backup right after you apply the new firmware and reboot.

6. If you are really paranoid, you might also choose to reboot before you apply the firmware to release as many resources to the system for the update process as possible.

7. After the upgrade, login via PuTTY via serial or SSH  and do a "diag debug crashlog read" and "diag debug config-error-log read" (under normal ops, the crashlog should only show the AV DB loading and restarting after updates, you can issue "diag debug crashlog clear" to flush these events if you have a ton in the buffer).

8. If you are experiencing issues, enable SYSLOG or check System Events in your FAZ if you have one.  Very difficult to troubleshoot without historical logging that you can review.  Having these logs will quickly expose specific daemons that might be having issues such as IPS or AV.  Also having this info will help the TAC when diagnosing any issues.

[seadave]

I see Steve, if they want to be IT Cowboys at least it will give you more business :)  Sounds like an opportunity to get them on a FortiManager you provide so you can keep current copies of their configs and save them from their self induced escapades.

[emnoc]

They have the  revision controls as another options for cfg details and differences between. As long as the revision are saved and not deletec, these will be present and by fortiOSVersion-#

I never heard of a accidental upgrade  btw ;) Either you select it or if you push from the "local workstation" than it's very hard to claim a accident. Now if you don't follow the upgrade migration  suggestions that's another story..

Ken

[Steve_Fuller]

Ken have no idea what you mean by revision controls. The client pressed it because backup and upgrade seemed safer that upgrade alone--it's that simple.  And sounds like Fortinet agreed since it's been changed in later versions.

[emnoc]

It in the gui status next to the  "backup ugrade" buttons but from the cli

 config system global      set revision-backup-on-logout enable  end   execute revision list

This will allow you  to  find the  revision and restore back and by what fortiOS version. So if a "accidental upgrade happens" revert back the flash partition and  revert back the  configuration.

if you have a fortiManager use it  for upgrading the FGT/FWF appliance and set a schedule task, this will eliminate any "accidental upgrades" ;)

Ken

[Steve_Fuller]

Doesn't sound like that is available on entry level utils--80e and below.  We create backups on our server and the customer's servers.