A message from the management
jdh-sdx.homeunix.org is the name of a server dedicated to SDx. (jdh-sdx.kicks-ass.net also works, but we should probably use the more family-friendly name, and reserve this one for testing purposes.)
This server is not backed up yet, it's not on UPS, it's in my office and Josh likes to bang on the keyboard from time to time. I plan to fix most of this (aside from UPS - I'm too cheap) in the meantime use at your own risk and please respect the fact that this is behind my firewall so don't start serving up naked pictures of Britney Spears ...
Server Specs
- AMD K63-400
- 128 MByte RAM
- 13 GByte HDD
- RH Linux 7.3
- DNS name jdh-sdx.homeunix.org via http://www.dyndns.org
DNS name management
The DNS name for this system is provided via [DynDNS]. See SDx Internet Services for access information. Should there be problems with the domain name, feel free to investigate and correct it.
Server Tasks To Do
- At some point we will want to upgrade to server grade equipment - but for now we have plenty of horsepower and storage for our two main requirements (/ftp & /cvs). Once we have a backup procedure in place we can be less concerned with equipment failure.
- Within 35 days I need to install and configure a client to monitor IP address changes and automatically re-register with dyndns.org
Current Services
Services currently running:
- /ftp
- /cvs - details of the cvs service running on jdh-sdx. For more general info see /CVSInfo
- /ssh - details of your initial accounts can also be found on this page
- /www - details of our web server
Planned Services
Services planned:
- Automated /backups
- subversion (a better cvs)
Suggestions
All suggestions greatly received.
- Outgoing email - so "production updates" can be automated on cvs commits. See notes below.
- JSP engine (tomcat? or a better one?)
- J2EE server (JBoss)
Notes on outgoing email (DWM):
I experimented a little bit with sending email from jdh-sdx, and I think the minimum that you need is something that will translate internal names to acceptable external ones. Right now, if I send email from my account, the sender appears to be dwm@localhost.localdomain. Jdx-sdx sends the email directly to the destination host, which refuses to accept it. I can think of two reasons that it bounces, and both might apply: The receiver can't identify the sending server because it can reach some other identifying service there. And/or, the message envelope's From: address contains a bogus domain name (dwm@localhost.localdomain).
The simplest thing you can try in order to get this working is to edit /etc/mail/sendmail.mc. Find the line with "smtp.your.provider", replace that string with your ISP's outgoing SMTP server name. Save the file, and in the /etc/mail directory, run 'make'.
To send mail from the command line for testing, do something like this:
$ mail dmuller@spookydistance.com
You'll be prompted for a subject. Then you won't be prompted at all -- just type in a message, ending it with a single line that contains only a period. You'll be asked for any CC: addresses; just hit return.
Wait a few seconds, then run mail without any arguments. This will put you in the command-line mail reader. If you figure out how to use this for anything other than a one-time read of new email, please let me know. I never could figure this damn thing out. In any case, if the message failed to be sent off of jdh-sdx, you should have a bounce message waiting for you here.
If that one-line change in sendmail.mc isn't good enough, then things will get more complicated, and it might be easiest to look for a simpler mailer that handles masquerading setups for outgoing mail. Sendmail configuration is a 1000-page book. (And yes, I am foolish enough to have this book. It seemed like some UNIX rite of passage to configure sendmail. But it's more like a hazing.)
One line change didn't seem to work (but make didn't seem to do anything so perhaps the change didn't take) -- JDH Rebooted (crude but effective way of ensuring my changes registered!) - still no joy
DWM] Gasp! You never need to reboot a Linux system! :-) Try "
/etc/init.d/sendmail restart
" next time. /etc/init.d contains scripts for starting/stopping/restarting all of your daemons. (This is assuming that sendmail actually runs as a daemon on your system, as opposed to running on-demand.)Hey, at least I did it with a reboot command - rather than yanking the plug - that's quite advanced for an MS weenie One more thought: Since this is not a terribly uncommon configuration, perhaps the GUI admin tools provide a simplified means of configuring this.
And yet another thought: I'm using Exim on my newer Debian system, and it it is simpler than Sendmail, however I have less experience with it so far.