|
osdir.com mailing list archive F.A.Q. -since 2001! |
|
|
|
Subject: SUMMARY: sendmail on solaris 9 woes - msg#00083List: os.solaris.managers.summaries
by Date: Prev Next Date Index by Thread: Prev Next Thread Index
This is a detailed summary because this is important info and I really want
to get this summary into the archives: I asked: > I have a sendmail question for the collective. I believe the problem > centers around the "new and improved" (harumph) sendmail shipped with > Solaris 9. > > I do not run sendmail in daemon (-bd) mode on clients; only the mailserver > will receive email. So on the client (Solaris 9 with patch 113575-04) I > have edited the submit.cf file in two places > change Cwlocalhost to Cwmailhost > and change D{MTAHost}localhost to D{MTAHost}mailhost. > I have edited the sendmail.cf file in one place > change the Cwlocalhost to Cwmailhost. > On the mailhost (an old Solaris 7 sparc 20, with patch 110615-09), I put > the local host name into the local-host-names file and restarted sendmail. > > Under Solaris 8 and older, this worked fine (and there was no submit.cf so > I didn't have to modify it...). With Solaris 9, there is this > new user smmnp, which will only send email to localhost. This is called > improving security -- forcing you to run a daemon that was previously > disabled... > > Has anyone gotten a Solaris 9 box to send email out without running it in > daemon mode? Summary: Ok, here is a recipe for running sendmail shipped with a Solaris 9 box in a secure fashion without running the daemon on the local system. * do not run sendmail in daemon mode. Create the file /etc/default/sendmail with the single line MODE= and then stop and restart sendmail. A typical ps after doing that will be smmsp 688 1 0 13:07:00 ? 0:00 /usr/lib/sendmail -Ac -q15m root 689 1 0 13:07:00 ? 0:00 /usr/lib/sendmail -q15m note that there is not a "-bd" in sight. * edit the /usr/lib/mail/cf/submit.mc file. change the last line from FEATURE(`msp', `[127.0.0.1]')dnl to FEATURE(`msp', `mailhost')dnl * compile the new submit.cf file cd /usr/lib/mail/cf m4 ../m4/cf.m4 submit.mc > submit.cf * copy this new submit.cf file into place cp /usr/lib/mail/cf/submit.cf /etc/mail/submit.cf * make sure that mailhost will accept mail from the server (may have to edit local_host_names and then restart sendmail on mailhost. * every time you apply a sendmail patch on this machine, rebuild the submit.cf file. * and by the way, Sun will tell you this cannot be done. They will say that you must run in daemon mode on every machine. +-----------------------------------------------------------------------+ | Christopher L. Barnard O When I was a boy I was told that | | cbarnard@xxxxxxxxxxxx / \ anybody could become president. | | (312) 347-4901 O---O Now I'm beginning to believe it. | | http://www.cs.uchicago.edu/~cbarnard --Clarence Darrow | +----------PGP public key available via finger or PGP keyserver---------+
Thread at a glance:
Previous Message by Date:SUMMARY: find commandIt seems what fixed the problem with the find command spanning across the remote file system was to remove the -local parameters. I had already tried -fstype ufs, but that didn't work either. This command DIDN'T go across remote file systems find / \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 This command DID go across remote file systems. find / -local \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 Seems backwards to me, but at least it now works as I intended. Many thanks to everyone that replied. John ----- Original Message ----- From: "John Elser" <jElser@xxxxxxxxxxxxxxxx> To: <sunmanagers@xxxxxxxxxxxxxxx> Sent: Friday, July 25, 2003 8:26 AM Subject: find command > I use the find command to send files to cpio for our nightly backups. The > problem that I'm having is that find wants to go down my remotely mounted file > systems (which takes a very long time to complete). Here's the command that > I'm running: > > find / -local \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 > > I'd also like to eliminate the /proc file system. > > x86 Solaris 2.5.1 > > Thanks, > > John > _______________________________________________ > sunmanagers mailing list > sunmanagers@xxxxxxxxxxxxxxx > http://www.sunmanagers.org/mailman/listinfo/sunmanagers Next Message by Date:SUMMARY: VxVM 3.5 patch and VxFS 3.5 MP1 rolling patchIt appears that these patches can be installed with little or no problem. Thanks to Topher Dick and Mads Vaagland. I appear to have both installed, and I don't seem to be having any issues -- to be fair, I think I may have just installed it with the media that had it on there... but the 3.5 install with those patches on about a dozen Solaris 9 systems seems to be working just fine -- I've not had any issues... toph Hi, We are using those patches on two of our Solaris 9 boxes, and have had no problems with them. We've just followed the installation instructions included with the patches. I should mention that the patches were applied agains fresh installations, no vxvm/fs volumes/filesystems existed on the boxes before the patches were installed. Hope this helps. - Tom Davis <tjdavis@xxxxxxxxxx> writes: > Does anyone who has applied patches 113207-05 and/or 112392-04 to VxFS > and VxVM respectively on Solaris 9 > have any caveats or warnings in regard to their experiences. I am > planning on applying those patches this weekend. > I don't have a test system to test these patches. Any comments, > concerns or warnings will be greatly appreciated. > > Thanks > Tom Davis Previous Message by Thread:SUMMARY: find commandIt seems what fixed the problem with the find command spanning across the remote file system was to remove the -local parameters. I had already tried -fstype ufs, but that didn't work either. This command DIDN'T go across remote file systems find / \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 This command DID go across remote file systems. find / -local \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 Seems backwards to me, but at least it now works as I intended. Many thanks to everyone that replied. John ----- Original Message ----- From: "John Elser" <jElser@xxxxxxxxxxxxxxxx> To: <sunmanagers@xxxxxxxxxxxxxxx> Sent: Friday, July 25, 2003 8:26 AM Subject: find command > I use the find command to send files to cpio for our nightly backups. The > problem that I'm having is that find wants to go down my remotely mounted file > systems (which takes a very long time to complete). Here's the command that > I'm running: > > find / -local \( -name remote1 -o -name remote2 \) -prune -o -print | cpio > -ovcC16384 > /dev/rmt/1 > > I'd also like to eliminate the /proc file system. > > x86 Solaris 2.5.1 > > Thanks, > > John > _______________________________________________ > sunmanagers mailing list > sunmanagers@xxxxxxxxxxxxxxx > http://www.sunmanagers.org/mailman/listinfo/sunmanagers Next Message by Thread:SUMMARY: VxVM 3.5 patch and VxFS 3.5 MP1 rolling patchIt appears that these patches can be installed with little or no problem. Thanks to Topher Dick and Mads Vaagland. I appear to have both installed, and I don't seem to be having any issues -- to be fair, I think I may have just installed it with the media that had it on there... but the 3.5 install with those patches on about a dozen Solaris 9 systems seems to be working just fine -- I've not had any issues... toph Hi, We are using those patches on two of our Solaris 9 boxes, and have had no problems with them. We've just followed the installation instructions included with the patches. I should mention that the patches were applied agains fresh installations, no vxvm/fs volumes/filesystems existed on the boxes before the patches were installed. Hope this helps. - Tom Davis <tjdavis@xxxxxxxxxx> writes: > Does anyone who has applied patches 113207-05 and/or 112392-04 to VxFS > and VxVM respectively on Solaris 9 > have any caveats or warnings in regard to their experiences. I am > planning on applying those patches this weekend. > I don't have a test system to test these patches. Any comments, > concerns or warnings will be greatly appreciated. > > Thanks > Tom Davis
blog comments powered by Disqus
|
|