I'm definitely a linux newbie and just want some basic help.

I was having problems with my webmail which the following command solved (runs a 2nd version of Exim listening on a different port) and I need to run the this command on boot so the fix stays in place:

exim -bd -oX '[0.0.0.0]:465' -tls-on-connect

how do I run this on boot after the main Exim service is loaded?

Thanks!

Richard.

Change that line to "/usr/sbin/exim -bd -oX '[0.0.0.0]:465' -tls-on-connect" to the file /etc/rc.local and place it just above the only uncommented line, which is exit 0. Now whenever your system boots, that command will be run. Some scripts need the full path to a file, which is why I added the /usr/sbin/ ahead of exim.

Really though, you should not be rebooting a server, particularly not a mail server. What happens if a message tries to come in while your machine is down?

Peace,
JimBass

Actually that's the question that I have been wondering for a while.

What do you do in a situation where you have to boot the system because of some updates or changes in the system which requires you to reboot. For example what if you upgrade your kernel?

There is only one type of change that requires a reboot on linux, and that is compiling/installing a new kernel. Unlike windows, adding new hardware (of the printer/usb type, obviously a new card plugged into the motherboard requires the machine to be off while doing that) won't require a reboot at all. Just a modprobe of the new driver modules.

Production systems by and large don't/shouldn't be rebooted. Yes you end up with an older kernel, but I've had production systems online for 4 years without a reboot. Some Debian Potato servers are still up with their default kernel from the install, which I think was 2.4.10 or something in that neighborhood. You have to watch the system, and be careful with it. Don't add unnecessary services, but by and large a problem with software can always be updated with a new version, but updating the kernel really shouldn't be done, save a serious kernel flaw, or known exploit that puts you at risk. If there is a problem in the X server, and you run a proper headless server, you have no problem, hence no update to worry about.

When you do have to reboot something, it is best to have multiple servers involved. DNS needs a minimum of 2 boxes, and any fool that runs multiple IP addresses on one box to get around that deserves whatever trouble they get themselves into for plain stupidity. Mail really should have 2 boxes as well, even if all the 2nd does is cache mail until the main mail server gets back online. You can do the same thing with web servers, by changing the DNS around so all traffic is directed at the machine that will be staying on, and reboot the one you direct the traffic away from.

If you're running one system at home on one public IP, that you're more or less SOL.

Peace,
JimBass

Thanks JimBass for your in-depth reply. I wonder what people do who runs Windows Mail Server when they add a hardware or when Microsoft releases patches and upgrades every month?

In principle, Jim is absolutely right. And he has experience on his side. But, rebooting a server isn't that big of a deal, especially a mail server. Rebooting a server shouldn't take more then 2-3 minutes if you didn't trim down your kernels. On diet-kernels (that is: only support build-in is for the actual hardware inside and nothing else) should take less time. If a message is to be delivered during the reboot-sequence, it won't be accepted. The sender (usually the mailserver from some ISP) will retry a few minutes later and by then your server is up and running again.

My

The way email systems are designed even if you have to reboot your mail server the sending mail server will hold mail for you in it's outgoing queue and try to re-deliver for up to four days (if configured properly) so you really shouldn't loose any incoming mail.

I ditched the secondary mail server due to the only mail it ever received was SPAM, because the spammers would always try to back-door by sending spam directly to the secondary mail server rather than the primary to try and dodge filtering. was just a waste of resources to run it.

Oh yes. Excellent point. Now I see why many people are able to reboot mail servers (specially windows) without losing the messages, as they are returned to the sender and I guess as Dutch Master;3069664 mentioned the sender's mail server will try couple of times before finally giving it up.

Yeah, sorry I wasn't trying to create FUD. Any server that fails to deliver will usually drop the message into the queue, to try again in an hour, than another, then 6,8,12,24 down the road, based on how the queue behavior is configured. What has happened to me more often than I desired was having one really important message get stuck in the senders queue for 12 hours. It isn't long in real life, but it is long in email time. I strongly urge you not to be on the phone with your CEO speaking to another CEO, where the other is insisting that he has a sent message to your CEO in his "sent" folder, but you haven't received it on your server.

Peace,
JimBass

No disrespect Jim, but that wasn't FUD and I'm not very happy you qualified my message that way...

1) you cannot be held accountable for the (mis)configuration of someone else's server. Any reasonable CEO would know and respect that. There are however unreasonable CEO's...
2) any selfrespecting sys-admin chooses his maintainance window carefully so no-one would notice (like: after hours or in a 24/7 company, during a shiftchange), communicate that with (senior) management in advance and makes sure that any work that can be done before taking a server offline is done.

Sorry Dutch Master, I wasn't implying the FUD came from you, it was caused entirely by me. When I read your message #6 I immediately felt terrible, seeing that I had implied that something as simple as a reboot could make mail undeliverable for long stretches of time.

I agree with everything you've said, sorry for the confusion.

I was caught in exactly the situation I described, with one CEO insisting he had sent the message (because he had, as far as his Outlook was concerned), but my CEO and mail server had not seen it yet. The other CEO had successfully transfered the message to his server, so it was considered sent, but it didn't get from their server to mine, and was in their queue for quite a while. We insisted they hadn't sent it (because from my machine's perspective they hadn't), and they insisted they did (because from his desktop's perspective, he had). By the time I got to speaking to one of their postmasters, the queue had spit the message out to me, and I forswore doing clamav/spamassassin updates when new versions came out! When the first attempt at delivery happened, I had shut down mail as I upgraded either spamassassin or clamav to the new stable version. It was down maybe 10 minutes in total, but by being the wrong 10 minutes, I had to endure a fair amount of heat, both from my CEO at the time and had to sort out an email war. Both CEOs involved were pretty unreasonable!

Peace, and again, sorry for the confusion,
JimBass

http://smileys.on-my-web.com/reposit...omputer-22.gif
No problem Jim, I think this was a prime example of misunderstanding eachothers words. I'll grab a spade to bury the whole thing, wanna join in?

http://smileys.on-my-web.com/reposit...dshake-147.GIF

Sure man, sounds like a fine plan!

Peace,
JimBass