There is nothing special about patching Ubuntu vs. Windows, RHEL, CentOS, SuSE, debian, etc.
The basic state of mind you need to be in when designing your patch procedure is to assume something will break.
Some of the basic guidelines I tend to use when designing a patch setup are:
- Always use a local system to centralize internally to your network where the patches are installed from
This may include using WSUS, or mirrors of
<your_os_here> to an internal patch management machine. Preferable one that can centrally query and let you know the status of patches installed on your individual machines.
- Pre-stage the installations - when possible - on the machines.
When it is possible, as patches come out have the central server copy them down to the individual machines. This is really just a time saver so that you don't have to wait for them to download AND install, you just have to kick off the install during your patch window.
- Get an outage window to install the patches in, you might have to reboot, and something probably will break. Make sure the stake holders for those systems are aware there are patches being deployed. Be prepared for the "this" doesn't work calls.
In keeping with my basic theory that patches break things, make sure you have an outage window to apply patches long enough to troubleshoot critical problems, and possibly roll the patch back. You don't necissarally need to have people sitting there testing after patches. Personally I rely heavily on my monitoring systems to let me know everything is functioning at the very minimum level that we can get away with. But also be prepared for little nagging issues to be called in as people get to work. You should always have someone scheduled to be there ready to answer the phone - preferable not the guy who was up till 3am patching the boxes.
- automate as much as possible
Like everything else in IT, script,script then script some more. Script the package download, the installation start, the mirror. Basically you want to turn patch windows into a baby sitting assignment that just needs a human there in case things break.
- Have multiple windows each month
This gives you the ability to not patch some servers if for whatever reason they can't be patched on "the appointed night". If you can't do them on night 1, require they be free on night 2. Also lets you keep the number of servers patched at the same time sane.
Most importantly keep up with the patches! If you don't you'll find your self having to do very large 10+ hour patch windows just to get back to the point where you are caught up. Introducing even more points where things could go wrong, and making finding which patch caused and issue that much harder.
The other part of this problem is, keeping up with patches is 'a good thing', but patches are released almost daily. How many scheduled outages does one have to make if there is a new security patch available every single day?
Patching a server once a month or once every other month is - IMHO - a very achievable, and acceptable goal. More than that, and well you'll constantly be patching servers, much less and you start getting into situations where you have hundreds of patches that need to be applied per server.
As far as how many windows you need a month? That depends on your environment. How many servers do you have? What is the required up time for your severs?
Smaller environments that are 9x5 can probably get away with one patch window a month. Large 24x7 shops may need two. Very large 24x7x365 may need a rolling window every week to have a different set of servers patched each week.
Find a frequency that works for you and your environment.
One thing to keep in mind is that 100% up to date is an impossible goal to reach - don't let your security department tell you otherwise. Do your best, don't fall too far behind.