Sponsored Content
Full Discussion: Sendmail Upgrade Delimna
Operating Systems Solaris Sendmail Upgrade Delimna Post 302331558 by buckhtr77 on Monday 6th of July 2009 02:27:01 PM
Old 07-06-2009
Sendmail Upgrade Delimna

I'm being forced to upgrade my Sendmail to version 8.14.2. We currently run what comes stock with the Solaris 10 build. I've been working on this for several days getting Sendmail installed and running again. Now it's telling me that I have to install Berkely database. I've never done this before. Is there a simpler way to upgrade this w/out all the gotchas that I've encountered. Thanks.
 

5 More Discussions You Might Find Interesting

1. Red Hat

Upgrade

Dear all, Requirement: Upgrade RHEL 3 to RHEL 5. Question: How to plan the upgrade? Present state: Know that there is no direct upgrade path visible. And RH does not support direct upgrade. H/W: HP Proliant DL 380 G4 TIA (1 Reply)
Discussion started by: earlysame55
1 Replies

2. Solaris

Sendmail not quite working after upgrade

We have a machine that we upgraded today. After the upgrade, I am getting connection refused on any emails from a remote host that uses an alias. If I send email directly to a user on the upgraded host, from a remote host, that works fine. If I send email to an alias on the ugraded machine, from... (3 Replies)
Discussion started by: brownwrap
3 Replies

3. UNIX for Advanced & Expert Users

Sendmail questions, SCO 5.0.6 sendmail 8.11.0

I am running SCO 5.0.6 and using sendmail 8.11.0 and having issues with smtp authentication. When trying to send mail the following message will kick back. (reason: 530 5.7.1 Authentication required) 530 5.7.1 Authentication required Not sure what needs to be tweeked in sendmail.cf but I... (1 Reply)
Discussion started by: ziggy6
1 Replies

4. AIX

Sendmail not logging after upgrade to 7.1 TL2 SP3

Has anyone seen an issue where sendmail stops logging any debug messages after upgrading to 7.1 TL2 SP3? The only APAR I see is for a "priv_raise failed" message in syslog. Thanks. (1 Reply)
Discussion started by: tommysalami
1 Replies

5. Solaris

Clarifying sendmail configuration - sendmail-client offline

Hi all, I have read about sendmail running as 2 separate process. 1 as a MSP, and the other as the real daemon or MTA. In my current configuration, the sendmail-client is disabled. Both submit.cf and sendmail.cf are left as default untouch I do not specified any mailhost... (3 Replies)
Discussion started by: javanoob
3 Replies
DH_INSTALLINIT(1)						     Debhelper							 DH_INSTALLINIT(1)

NAME
dh_installinit - install init scripts and/or upstart jobs into package build directories SYNOPSIS
dh_installinit [debhelperoptions] [--name=name] [-n] [-R] [-r] [-d] [--params] DESCRIPTION
dh_installinit is a debhelper program that is responsible for installing init scripts with associated defaults files, as well as upstart job files into package build directories. It also automatically generates the postinst and postrm and prerm commands needed to set up the symlinks in /etc/rc*.d/ to start and stop the init scripts. FILES
debian/package.init If this exists, it is installed into etc/init.d/package in the package build directory. debian/package.default If this exists, it is installed into etc/default/package in the package build directory. debian/package.upstart If this exists, it is installed into etc/init/package.conf in the package build directory. OPTIONS
-n, --noscripts Do not modify postinst/postrm/prerm scripts. -o, --onlyscripts Only modify postinst/postrm/prerm scripts, do not actually install any init script, default files, or upstart job. May be useful if the init script or upstart job is shipped and/or installed by upstream in a way that doesn't make it easy to let dh_installinit find it. -R, --restart-after-upgrade Do not stop the init script until after the package upgrade has been completed. This is different than the default behavior, which stops the script in the prerm, and starts it again in the postinst. This can be useful for daemons that should not have a possibly long downtime during upgrade. But you should make sure that the daemon will not get confused by the package being upgraded while it's running before using this option. -r, --no-restart-on-upgrade Do not stop init script on upgrade. --no-start Do not start the init script on install or upgrade, or stop it on removal. Only call update-rc.d. Useful for rcS scripts. -d, --remove-d Remove trailing d from the name of the package, and use the result for the filename the upstart job file is installed as in etc/init/ , and for the filename the init script is installed as in etc/init.d and the default file is installed as in etc/default/ . This may be useful for daemons with names ending in d. (Note: this takes precedence over the --init-script parameter described below.) -uparams --update-rcd-params=params -- params Pass params to update-rc.d(8). If not specified, defaults will be passed to update-rc.d(8). --name=name Install the init script (and default file) as well as upstart job file using the filename name instead of the default filename, which is the package name. When this parameter is used, dh_installinit looks for and installs files named debian/package.name.init, debian/package.name.default and debian/package.name.upstart instead of the usual debian/package.init, debian/package.default and debian/package.upstart. --init-script=scriptname Use scriptname as the filename the init script is installed as in etc/init.d/ (and also use it as the filename for the defaults file, if it is installed). If you use this parameter, dh_installinit will look to see if a file in the debian/ directory exists that looks like package.scriptname and if so will install it as the init script in preference to the files it normally installs. This parameter is deprecated, use the --name parameter instead. This parameter is incompatible with the use of upstart jobs. --error-handler=function Call the named shell function if running the init script fails. The function should be provided in the prerm and postinst scripts, before the #DEBHELPER# token. NOTES
Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command. Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts. SEE ALSO
debhelper(7) This program is a part of debhelper. AUTHORS
Joey Hess <joeyh@debian.org> Steve Langasek <steve.langasek@canonical.com> 9.20120909 2012-04-10 DH_INSTALLINIT(1)
All times are GMT -4. The time now is 02:13 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy