Subject: SUMMARY: telnet not working - msg#00137

Previous Message by Date: click to view message preview

SUMMARY: Patch management

Thanks to: Greg Gallagher Mathew Atkinson Simon McCartney Eric Horne Sergio Gelato Everyone had some very interesting and clever tricks for patch management using patchdiag and scripts. Much more clever than I have ever been I must admit. Special thanks to Greg for the following link: http://astro.uchicago.edu/~davidr/cfengine-tools/ If I were going to manage patches I would have used this extensively. However, we have decided that it just wasn't worth the hassel. Instead we will use Solaris' new flash archive and just rebuild our clients every 6 months. With flash archive we've gotten a rebuild down to 20 minutes including the cfengine run. So we could rebuild 15 boxes every hour, making a complete floor rebuild possible in less than a weekend. Better and easier than trying to manage individual patches in our opinion. We met with Mark Burgess when he was here for the Lisa conference (cfengine creator) and it was also his opinion that patch management was easier this way, which is what finally tipped us in that direction. Cfengine, he said, was never designed for patch management nor will it be. 'Nuff said. ~JK Jeff Kennedy wrote: > > We are having issues with patch management and I am wondering what other > people are doing in a medium sized environment. > > I have approx. 500 Sun workstations running a mixture of Solaris 7 and 8 > and need to keep up with patches on these. I have looked at PatchReport > which seems to have some definite possibilities but before I start > building I wanted to get some input from this forum as to how you handle > it. > > The requirements are these: > > single patch master pulls patch list from Sun across internet > all clients pull from patch master > recommended/security patches are fully automated > application specific patches are given as an argument or in a file > these patches are pulled only by the clients running the application > > I think what I am looking for is cfengine for patch management, but I'm > open to suggestions. > > Thanks. -- ===================== Jeff Kennedy Unix Administrator AMCC jlkennedy@xxxxxxxx

Next Message by Date: click to view message preview

SUMMARY - Repeating emails

I got A LOT of responses. Most people wanted the answer as soon as I got it, but I did get some suggestions. Some people suggested using other mail programs such as qmail or postfix or notes. A few pointed at the firewall, but that's not the case. One reply (no name, just "sysadmin@<domain>") suggested using procmail, but asked why I don't just send SUCCESS. The answer is that the remote server doesn't hear it or doesn't listen and resends the message. I think that there's a mail lock problem on the remote, and that the queue is read too frequently. It's not sendmail per se, but if it were, it would probably have been started like this: /usr/lib/sendmail -bd -q5s If you DID start sendmail like that, the known-to-work file locks would prevent concurrent children from delivering the same queue entry simultaneously. And people think I should get rid of it? Why?? I did get suggestions to check that /var/mail/${USER} is set to mail and not the users' group. There are a few "wrong" groups, but those users never have this problem. The other suggestion was to check the delivery flags on Mlocal and remove the "m". Thanks to Brad Parks for both of those, but I'm way ahead of you on Mlocal. I didn't know about the group thing, but it's not that. We've narrowed it down to THREE conditions that cause the same message to be received as many as 400 times from a remote server: 1 - Mailing List program went crazy and sent multiple copies. This usually results in the user receiving only ten or twenty copies. Remote domain admin will flip the switch and stop it from happening as he/she apologizes. 2 - The message comes from a particular domain who shall remain nameless because it seems they don't know what they're doing. I found out by looking at the logs that about a third of all messages from this domain are resent at least two times (total 3 messages) and that at least one per week is resent not less than 100 times. Remote domain has no admin, only an "abuse" address, and will send a form letter stating that the apparently offending address is not valid and is being forged. Then they give us an URL on how to prevent spam. 3 - MIME content length is wrong. The spool runs out so the delivery MTA keeps sending the message until the length is correct (never) or until the max time is spent on the queue (5 days) or until I tript REJECT and start getting complaints from all the bounces. Remote admin will usually remove the queue and everything will be fine. We both apologize ;) Conclusion: SendMail, while many of you may think is klunky and unmanageable, is NOT the problem here. The problem is the way a certain NON-RFC-compliant mail server does not listen when an RFC-compliant server talks. Solution: So long as bad delivery agents are allowed to exist, there appears to be no real solution. However, as soon as I find the answer I will post it to the list. Happy Holidays to all. Snippit from original message: Does anyone know if it is possible to configure SendMail to check the headers for the Message-Id: line and refuse it if it has already been delivered? That would seem the most logical thing to do. If this is not possible, then could it somehow be otherwise configured to recognize a message has been received more than once and give the remote server the "Enough Already!" signal?

Previous Message by Thread: click to view message preview

SUMMARY: Patch management

Thanks to: Greg Gallagher Mathew Atkinson Simon McCartney Eric Horne Sergio Gelato Everyone had some very interesting and clever tricks for patch management using patchdiag and scripts. Much more clever than I have ever been I must admit. Special thanks to Greg for the following link: http://astro.uchicago.edu/~davidr/cfengine-tools/ If I were going to manage patches I would have used this extensively. However, we have decided that it just wasn't worth the hassel. Instead we will use Solaris' new flash archive and just rebuild our clients every 6 months. With flash archive we've gotten a rebuild down to 20 minutes including the cfengine run. So we could rebuild 15 boxes every hour, making a complete floor rebuild possible in less than a weekend. Better and easier than trying to manage individual patches in our opinion. We met with Mark Burgess when he was here for the Lisa conference (cfengine creator) and it was also his opinion that patch management was easier this way, which is what finally tipped us in that direction. Cfengine, he said, was never designed for patch management nor will it be. 'Nuff said. ~JK Jeff Kennedy wrote: > > We are having issues with patch management and I am wondering what other > people are doing in a medium sized environment. > > I have approx. 500 Sun workstations running a mixture of Solaris 7 and 8 > and need to keep up with patches on these. I have looked at PatchReport > which seems to have some definite possibilities but before I start > building I wanted to get some input from this forum as to how you handle > it. > > The requirements are these: > > single patch master pulls patch list from Sun across internet > all clients pull from patch master > recommended/security patches are fully automated > application specific patches are given as an argument or in a file > these patches are pulled only by the clients running the application > > I think what I am looking for is cfengine for patch management, but I'm > open to suggestions. > > Thanks. -- ===================== Jeff Kennedy Unix Administrator AMCC jlkennedy@xxxxxxxx

Next Message by Thread: click to view message preview

SUMMARY - Repeating emails

I got A LOT of responses. Most people wanted the answer as soon as I got it, but I did get some suggestions. Some people suggested using other mail programs such as qmail or postfix or notes. A few pointed at the firewall, but that's not the case. One reply (no name, just "sysadmin@<domain>") suggested using procmail, but asked why I don't just send SUCCESS. The answer is that the remote server doesn't hear it or doesn't listen and resends the message. I think that there's a mail lock problem on the remote, and that the queue is read too frequently. It's not sendmail per se, but if it were, it would probably have been started like this: /usr/lib/sendmail -bd -q5s If you DID start sendmail like that, the known-to-work file locks would prevent concurrent children from delivering the same queue entry simultaneously. And people think I should get rid of it? Why?? I did get suggestions to check that /var/mail/${USER} is set to mail and not the users' group. There are a few "wrong" groups, but those users never have this problem. The other suggestion was to check the delivery flags on Mlocal and remove the "m". Thanks to Brad Parks for both of those, but I'm way ahead of you on Mlocal. I didn't know about the group thing, but it's not that. We've narrowed it down to THREE conditions that cause the same message to be received as many as 400 times from a remote server: 1 - Mailing List program went crazy and sent multiple copies. This usually results in the user receiving only ten or twenty copies. Remote domain admin will flip the switch and stop it from happening as he/she apologizes. 2 - The message comes from a particular domain who shall remain nameless because it seems they don't know what they're doing. I found out by looking at the logs that about a third of all messages from this domain are resent at least two times (total 3 messages) and that at least one per week is resent not less than 100 times. Remote domain has no admin, only an "abuse" address, and will send a form letter stating that the apparently offending address is not valid and is being forged. Then they give us an URL on how to prevent spam. 3 - MIME content length is wrong. The spool runs out so the delivery MTA keeps sending the message until the length is correct (never) or until the max time is spent on the queue (5 days) or until I tript REJECT and start getting complaints from all the bounces. Remote admin will usually remove the queue and everything will be fine. We both apologize ;) Conclusion: SendMail, while many of you may think is klunky and unmanageable, is NOT the problem here. The problem is the way a certain NON-RFC-compliant mail server does not listen when an RFC-compliant server talks. Solution: So long as bad delivery agents are allowed to exist, there appears to be no real solution. However, as soon as I find the answer I will post it to the list. Happy Holidays to all. Snippit from original message: Does anyone know if it is possible to configure SendMail to check the headers for the Message-Id: line and refuse it if it has already been delivered? That would seem the most logical thing to do. If this is not possible, then could it somehow be otherwise configured to recognize a message has been received more than once and give the remote server the "Enough Already!" signal?