Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Failures always occur during the most inopportune time. My backups=20 stopped when I upgraded releases and failed to restart the crontab. Our=20 BLU failure occurred after we had changed authentication so that we were = not doing backups. The way I am set up in the office is I have a nightly = backup which is subsequently backup up to NY. Neither I nor the NY IT=20 guys noticed that nothing was getting updated for a while. It turned out = to be similar to the BLU authentication thing. Somehow the backup server = was not being authenticated by the NFS server. A close look at the logs=20 showed the obvious. On 06/09/2009 02:24 PM, Richard Pieri wrote: > On Jun 9, 2009, at 11:11 AM, Jerry Feldman wrote: > =20 >> One way to get around this is to have a daily log message go out. =20 >> Recently we had an issue with one of the BLU servers where we were =20 >> not receiving the daily log watches. The issue was that GMAIL's SPAM = >> filters shuttled them into the SPAM box, so the server was ok. >> =20 > > > Indeed. In principle it's best to have several independent layers of = > monitoring with independent notification channels. Something to watch = =20 > the watcher, so to speak. > > =20 --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |