Hot answers tagged patch
I have worked in development as a release manager, build engineer, setup developer and as an application packager and deployment engineer in large corporations. This is a review of the best (and worst) conceptual and real-world features of MSI. The most common design problems found in MSI files are presented as a separate answer below. I also want to ...
Just a few benefits: Can be advertised. So that on demand installation could take place. Like advertisement, features can be installed as soon as the user tries to use them. State management is maintained so Windows Installer provides a way to let administrators see if an application is installed on a machine. Ability to roll back if an installation ...
This answer is very much a work in progress and a rough outline. Additions, questions and updates welcome. This list is by no means exhaustive. Add a comment with information about troublesome packages. Typical Problems and Design Flaws Seen in MSI Packages I must also warn that a lot of MSI files contain errors, sometimes serious ones, but trained ...
You're looking for diff -rq (dir1) (dir2) Proof of concept: #!/bin/sh #create our test mkdir -p /tmp/a/b echo "test" >> /tmp/a/c mkdir -p /tmp/a/d/e echo "blah" >> /tmp/a/d/e/f #only exists here mkdir -p /tmp/q/b echo "testing" >> /tmp/q/c #/tmp/a/c shouldnt match mkdir -p /tmp/q/d/e echo "blah" >> /tmp/q/d/e/g #only exists here ...
All you need to do is sudo yum install patch
I update firmware in two key instances. When staging up a server. When I just get the server, I'll check the the HP web-site for the date of their latest "Firmware Update CD". If it's new enough, I'll run it against the server before bringing it up to production. When I repurpose a server. Typically, this server is 2-5 years old and probably hasn't had a ...
You should never touch anything in production unless there's a good reason to do so. Security updates are a very good reason. And as Iain mentions, testing beforehand helps you to ensure that nothing is likely to go wrong when you apply the updates to your production system.
well - most stable way is to stay with what distro provides. 2nd safest would be to use official backports, but it seems php 5.3 is not there. otherwise you have to rely on your own [if you compile and build package by yourself or 3rd party contributors. quick googling returns this as one of repositories [ x86 only ] of php 5.3 for ubuntu 8.10 : ...
Software maintenance in AIX is complicated and alien to the uninitiated. These days, major major AIX OS updates are referred to as a "maintenance level" (ML) and revisions to those code drops are referred to as "service packs" (SP). You'll want to determine what level you systems are currently at and the level you wish to upgrade to prior to starting the ...
This issue has now been resolved with the help of Microsoft tech support. It involved some registry changes on the part of them to svchost. It apparently is a known issue with vista/2k8 and solved in 2k8r2/win7. More info to come, they promised to let me know more next week.
The Dell nomenclature you're looking for is the "Server Update Utility", or SUU. They're bootable ISO images containing firmware updates. I believe they're still released quarterly. You can get fancier with ESX, since it will allow third-party software, and install Dell OpenManage Agents directly onto the hosts to allow more detailed remote monitoring if ...
You just need to include the -q flag to make it brief: # diff -q dir1 dir2 Files dir1/both and dir2/both differ Only in dir1/: one Only in dir2:/ two
Secunia has an application /OS / hardware appliance vulnerability database which has the info you are looking for. IE6 Report page for example. and Java JRE 1.2.x
There might be a better way, but this might work, albeit not that efficiently: rsync -vrn / dest:/ > ~/file_list Then edit test to remove the stats, then: while read file; do diff $file <(ssh dest "cat $file") done < ~/edited_file_list Another Option: You might also consider mounting the file system with something like sshfs/fuse, and ...
Assuming you're using bash/sh/zsh etc... cd /path/to/source for i in /path/to/patches/*.patch; do patch -p1 < $i; done
I've had Ubuntu package updates wreck serious havoc in the recent past, so my recommendation would be to manually deploy the packages at this point, (after some testing or at least a VM snapshot) with something like apticron to send you an email about pending patches. That said, a central update management tool would be far better. Unfortunately, there ...
As you've surmised, a "loaded" patch panel is loaded: Connectors are pre-installed (usually all one family of connectors: e.g. the whole panel is going to be RJ45 cat6), while an unloaded patch panel is - well - not. Typically unloaded panels have empty holes (or knockouts) where connectors would go. There are a few practical differences as a result: ...
Add to your /etc/apt/apt.conf: APT::Default-release "stable"; And then you can run: aptitude install doxygen/wheezy (isn't the same thing as with -t)
I'll add to Michael's statement of the bleedin obvious with one of my own You should never touch anything in production unless there's a good reason to do so and you have tested it beforehand.
We stay a month behind (it's a nice round number) and also keep a separate group for machines that shouldn't auto-reboot. We also make a specific effort to exclude service packs, new versions of IE, and other major upgrades from the patch management system, taking the view that as these constitute a major upgrade you want to be physically there to see it ...
Shavlik's NetChk Protect could be a good option for you. The company has a close relationship with Microsoft and its underlying technology powers Microsofts own Baseline Security Analyzer product. Whilst Microsoft's MBSA only supports patching Microsoft products NetChk Protect support products from many other vendors.
We use HP SIM (System's Insight Manager) to roll out firmware, we do it by platform - test first, then development, then integration, then reference then finally production - usually about a week or so per platform so we have a 5/6 week release to production window. Seems to work but one thing we NEVER do is roll out firmware at the same time as other ...
Any package which installs/upgrades a running daemon will need a restart for that daemon. This is usually a very quick process, just a blip in service availability. The only packages which need a reboot are kernel updates. You cannot upgrade a kernel without a reboot. glibc updates may need you to restart a lot of services, or a reboot. However, given that ...
I've had success with these packages :) Hope it helps!
I think you should understand this in terms of a different approach to security. The Suhosin patch changes some fundamental ways variables and streams are handled and takes a more hard line approach about what is even possible with the language. It is not that PHP itself is not patched to include protection against known compromises, but as a language they ...
I think it depends on your situation - you have to weigh up the risks. How much damage could be caused by an update going awry? Is this a production server processing orders in realtime? Would an hour of down-time cost you a lot of money? If you don't run automatic updates you're more exposed to hackers and zero-day exploits. How much damage could a hacker ...
My rule of thumb based on years of building server rooms: Minimize cross-rack cabling as much as possible. The 300 port rack for the edge ports is far from full so you can place the edge-switches in the same rack. This keeps most of the cabling in the same rack. The 3 racks to the left: I presume those hold your servers. Fit a cheap gigabit switch in ...
This task is going to be extremely tedious. The best way to do it is to get a tone generator tool. Plug the tone generator into each user jack and then go to the patch panel and see which jack the tone is in with the wand; then, check the connection to see you have the right jack, and it's traced. The other thing to do is make a loopback cable that ...
Will this display field list anything if updates were displayed manually? Yes. You can also View Update History using the link in the left, which will list it, among other methods, like checking installed updates in the control panel, or running systeminfo from a command line.
Only top voted, non community-wiki answers of a minimum length are eligible