Building ports in debug mode

Lately, Amarok’s Ipod handling has been acting up — Amarok crashes immediately when trying to add music to the Ipod.

So, I wanted to do some debugging using the gnu debugger (gdb) to figure out what’s wrong, but I forgot to build Amarok with the debugging symbols.

There’s more than one way to do it.  I can set options in /etc/make.conf (which sets build options globally), or I can set the debug option at build time for just Amarok.  I decided to do the 2nd one, since everything else is working.

To set build options on a port, you use the -D flag, and specify the variable, so in my case it’s the DEBUG flag.

So:

cd /usr/ports/audio/amarok
make install -D DEBUG

[wait for the compiler to do its thing]

then I’ll run

gdb amarok

)run

and we’ll see what’s up.  If you wanted to run debugging for all your port builds, apparently you can set the variable
DEBUG_FLAGS=-g

in /etc/make.conf

Upgrading without overloading the CPU

There are a few different ways to keep a FreeBSD system up to date.
Portupgrade is my favorite way, but building  ports from source can be slow on slower systems, possibly making the system laggy for days at a time.  I know of two solutions to this problem.

1. Force portupgrade to use packages where available.
To go this route, just run portupgrade with the -P switch:

#portupgrade -aRrP

This will allow portupgrade to use packages instead of having to do all that compiling — good on slow machines, but you do lose control over compile time options.  Note that you still have to keep the ports tree up to date (using for example portsnap) when using this option.

2. “Renice” portupgrade’s process group to make all the portupgrade processes run at lower priority.

Two ways to do this, depending on whether portupgrade is already running:

A. If portupgrade is already running:

-Find out what the process id (pid) of the currently running portupgrade is:

#ps -a |grep portupgrade

8814   p2  S+     0:00.15 /usr/bin/script -qa /tmp/portupgrade20091007-37088-d7pur8-0
env UPGRADE_TOOL=portupgrade UPGRADE_PORT=wxgtk2-2.8.

37088  p2  I+     8:30.59 ruby18: portupgrade: [50/167] wxgtk2-2.8.10 (ruby18)

note that using grep gets rid of the header, so it can be a bit confusing.  That first column is the PID.  Now, let’s find the process group (PGID) for 37088

#ps 37088 -ao pid,pgid,command                                                                                                ~
PID          PGID       COMMAND
37088        37088      ruby18: portupgrade: [50/167] wxgtk2-2.8.10 (ruby18)

Note that in this case, the PID and PGID are the same number.  I’m not sure if that’s always true with Portupgrade, but you definitely want to renice the process group, not just the currently running process.  Otherwise, the “niceness” will wear off once our currently upgrading port is finished building.

-Now, we want to “renice” that process group (lower its priority):

#renice 10 -g 37088
37088: old priority 0, new priority 10

This command lowers the priority of process group 37088.  You can experiment with different levels of “niceness” (I used 10) depending on what you want to do.

B. If portupgrade isn’t running yet:
This should be far easier, and more straightforward.  I would go this route all the time if only I could remember to do so.

#nice -n 10 portupgrade -aRr

Tips and tricks:

- Tip #1: Portupgrade status:
Did you know you can check the status of a large portupgrade job (like portupgrade -a) by just checking the process?  Remember how earlier we ran

#ps -a |grep portupgrade

and it returned:

37088  p2  I+     8:30.59 ruby18: portupgrade: [50/167] wxgtk2-2.8.10 (ruby18)

Well, check out that part of the line that says [50/167].  That gives us an idea of how far along we are.  On that particular system, it’s been a while since I’ve run portupgrade, so it has 167 total ports to upgrade, and it’s on port #50 of 167.  Someday, I’d sure like to see a utility that will convert this to a curses-style graph or something like that.  Perl has p5-progress, maybe that’d work.

-Tip #2 Batch upgrades.
If you’re doing a whole ton of unattended upgrading, you may want to set the BATCH=YES option in /etc/make.conf.  This will keep your portupgrade from being interrupted by all those options screens that pop up.  But I guess if you do that, you may as well use packages, because it’ll use the options you selected earlier.  Someday, it’d be nice to make the running system beep when it needs user input (as in those config screens).  I think there’s also a way to run all the configurations then to build, maybe with portmaster.

That’s all for now!

Scott

BSDCan2009 Presentations

There are some interesting tutorials over at the BSDCAN (BSD Canada) 2009 site:

Everything from Firewalls to VOIP, certification, hacking and commercial applications!

BSDCAN 2009 Site

Cheap USB printers and FreeBSD

Dru Lavigne says in her book “The Best of FreeBSD Basics,” “Somewhere there must be a theory stating that the amount of configuration knowledge required is directly proportional to the need for said configured service.  This is certainly often the case with printing.”

Well, for printing with a Samsung Laser Printer (ML-2510) under FreeBSD, she’s completely right. Not only was configuring the printer difficult, but it always felt like I was fighting against the natural order of things to make it work.

Linux / UNIX offer lots of ways to make printing happen. I wouldn’t call any of these ways elegant to a user –
it’s like having to learn how each component of your car functions before you can drive to the store.
Here’s the situation as best as I can describe it: Printing uses lots of little components.
Depending on what hardware you’ve got (i.e. what printer), those pieces parts will be different. As best as I can gather, here’s a diagram of what happens when I now print a document from the web browser:
[web doc]—->[postscript]—>[raster]—>[samsung language]

If I had one of those expensive printers that handles the postscript language directly (like an old-timey HP), I think those last two steps would be unneccessary.

FreeBSD by default uses something called LPD or Line Printer Daemon.  I usually like to stick with what it comes with (becuase that’s usually pretty wise), but in this case I gave up on LPD.

For the two things I need to be doing — printing to the printer, and printing to PDF, the alternative (CUPS) is much more mature and capable.
On to the configuration. Here’s a step by step account of what I did to make it work:
1. I ditched the default LPD (line printer daemon). I did this by editing /etc/rc.conf and commenting out the line that looks like

lpd_enable="YES"

(put a # in front of it)
2. I installed splix (open source samsung drivers):

cd /usr/ports/splix
make install clean

(note that this will also install cups if not already installed)
3. I enabled cups (a modern printing system): edit the /etc/rc.conf file and add the following:

cupsd_enable="YES"

4. start cups; run the following:

/usr/local/etc/rc.d/cupsd start

5. go to cups from a web browser. Use your web browser of choice and navigate to http://localhost:631 You should see the CUPS web interface. If not, recheck stops 3 and 4 above.
Now, click on “add printer.” Give it a short name (without spaces). I used SAMMY.
Give it a location. I used “Here”
And give it a description- call it whatever you want.
Click on continue. Select USB Printer #1. Click on continue.
Now it’s time to find the printer driver.
You might have luck going to samsung under “make”, then clicking continue and finding the printer model. Or you might have to tell it where the .PPD file resides. I had to navigate to /usr/local/share/cups/model/ml-2510.ppd, or maybe /usr/local/share/ppd/SAMSUNG/ml-2510.ppd
Anyway, once you find it, click on “Add Printer” to make it happen. CUPS should tell you it was added.

There are a couple more things you need to do before it’ll work right: 1. Open up the /usr/local/etc/printers.conf file, and look for Device URI. Change the line that says

usb:/dev/ulpt0

to read

file:/dev/ulpt0

Save that file 2. Install the cups to raster port: cd /usr/ports/print/cups-pstoraster make install clean (or package_add cups-pstoraster) 3. Change the permissions on /dev/ulpt0: edit (or create if it doesn’t exist) /etc/devfs.rules add the following text to that file:

[system=10]
add path 'ulpt*' mode 0660 group cups

4. Restart cupsd so all those changes can take effect:

/usr/local/etc/rc.d/cupsd restart

5. Test the printer to make sure it’ll print now: head to http://localhost:631 click on “printers” click on “print test page.” if it works, congratulations, that wasn’t easy. if you want to use lpd, I think you can still use foomatic-rip. Useful documentation / credits: ditdy had most of the info. The rest came from This post on the FreeBSD site.

Moving root / from one drive to another (better, faster, stronger)

So I had a 15kRPM drive and an Ultra 160 SCSI controller gathering dust, and decided to install both into the PIII 600 machine.  The onboard controller is only ATA/33, and so I’m thinking this might provide a performance boost.

Most of the manuals (including an article in the FreeBSD FAQ) said you really should reinstall the OS completely when you migrate from one disk to another.  I really didn’t feel like digging through /etc and figuring out what I missed later on, so I decided to just clone the disk.

There’s a handful of things I learned during this process…  First, RTFM (read the friendly manual), but use your head.  The FAQ (section 9.2) gives the following steps to migrate from one disk to another.

How do I move my system over to my huge new disk?

  1. newfs the new partition.
  2. mount it on a temporary mount point.
  3. cd to that directory.
  4. dump the old partition, piping output to the new one.
A couple of things:
-I forgot what ought to be step 0 above, to partition the drive.  Oddly enough, it still booted fine, but the machine was booting from a combination of the new drive and the old one.  Interesting…   Also, I edited /etc/fstab to make sure the new drive was mounted as /
-I forgot to switch the BIOS to boot to the SCSI controller.  So I fixed that (it was just a boot order issue.  Most BIOSes will have an option to boot off a different controller, usually on the boot order page.)
So I fixed that, and got “Invalid partition, no boot/loader” errors.  Reading and thinking about it a little bit,  I figured out that even though the drive had imaged successfully using the dump command in the FAQ, I hadn’t partitioned it!
And so it was addressing the drive directly, and I’d set it up in /etc/fstab to mount directly as da0.  Oddly enough this worked, kind of.

What I did to fix all this:
I ran sysinstall, and I went through the fdisk and drive labeling menu items.  I made sure that I set the boot flag on the partition.  I then imaged the disk as mentioned in the FAQ using the dump command, editing the fstab file to let the new drive boot up.
Here’s what I’d recommend if you’ve ever got to move your root partition:
1. before you do anything, make a backup, and download and burn the FreeBSD LiveFS CD. It wasn’t entirely clear from reading the FreeBSD download site which CD image would boot up and give the utilities I needed.  I’m sure it’s documented someplace.
The one marked “FreeBSD LiveFS CD” is probably the one you want.  I used that disc for booting at least half a dozen times to fix various things throughout the process.  I went into “Fix It” mode.  Mostly I used this for editing the /etc/fstab file with vi after I’d made a typo.
2. Use sysinstall to do the partitioning and formatting of the disk. Don’t forget to enable softupdates if that’s what you want.
3.  Use sysinstall to make your disk slices.  I learned the hard way that freebsd really wants its root directory (/) to be mounted from the “a” slice.  For example, if you’re using an IDE (ATA) disk, this might be ad0s1a.  For SCSI, it might be da0s1a.
4.  Mount your new drive to a temporary location.  (for example, mkdir /mnt/scsi; mount da0s1a /mnt/scsi.
5. Follow the procedure listed in the FAQ to dump data from the existing partition to the new drive:
# cd /mnt/scsi
# dump 0af - / | restore rf -

6. Edit the /etc/fstab file, replacing the old drive letter(s) with the new one(s).   Before you reboot, try and be sure you have it right.  You might need to ensure everything’s cool with the Master Boot Record (MBR).  Make sure you’ve got the boot disc handy, and that the BIOS settings are the way you want them (you want the boot disk to be booting first., somtimes this can get tricky when you’ve got multiple controllers.

7. Don’t neglect your swap partitions.  If any of these were on other disks before, you may need to change those in /etc/fstab too.  The system will probably still boot without swap, but you can run swapinfo to check the status of the swap.

Here are some other tools I used:
diskinfo:  a built in benchmarking utility.
disklabel: I didn’t use it directly, but more for listing the results of the changes made through sysinstall.
iostat: reports stats about your disk usage.

Setting up services not to listen on *

One of the greatest things about FreeBSD for servers is the jail infrastructure.  It lets you separate different services from each other, preventing things like cross-site attacks, and helping to minimize the damage if there is someday a breach.  It’s similar to chroot in the old days, and it generally makes sysadmins sleep better at night.

Reading more about jails and the best way to set them up, I learned that as a preliminary step, it’s important to make sure the host machine isn’t running services that listen on * (all available interfaces.)  Listening on “all interfaces” is something a lot of services do by default, but you can configure most of them not to do it.

Section6 Wiki lists a good way to list the services listening on *:

sockstat|grep "\*:[0-9]"

You can also try

sockstat -l

and look for items with a * listed under the local address column

I went ahead and drew up a chart of different services, and steps I took to reconfigure:

http://www.scottspare.com/docs/Service_listen_chart.pdf

(Section6 Wiki)

Bacula Message tweaks

Bacula tweaks: stopping those “boy who cried wolf” emails

Bacula is an open source backup program that “…comes by night and sucks the vital essence from your computers”

To be totally open about it, Bacula was hard to configure and use.  It’s just overkill for what I’m doing here. It separates the file-writing piece from the directing piece and the storage piece.   It was hard for me to learn how to use the console app because of the terminology.

Anyway, it’s installed, and it does run each night, as evidenced by its daily emails telling me it ran. Hey, Scott, I ran your backups. Your backups, I ran them. I get three of these emails daily, and I don’t want them unless it’s failing.
Here’s how to configure it so it only notifies you if something’s wrong. (if you’re anything like me, you’d be more likely to pay attention to its emails when it does have something important to say).

1. Open the /usr/local/etc/bacula-dir.conf file in your favorite text editor. I use vim.

2. Navigate down, down down into the depths of the file, and find the “Messages” section. Note that the word “Messages” is listed in several places, and you’ll probably have to skip several of them to get to the right spot. In my file, it’s close to the bottom, around line 378.

On a default configuration, it looks something like this:

Messages {

Name = Daemon

mailcommand = “/usr/local/sbin/bsmtp -h localhost -f \”\(Bacula\) %r\” -s \”Bacula daemon message\” %r”

mail = root@localhost = all, !skipped

console = all, !skipped, !saved

append = “/var/db/bacula/log” = all, !skipped

}

3. The line you want to change is that “mail =” line. Not the mailcommand line, or any of the other dozens of lines that say mail, just the mail line.

4. Change that line to read “mail on error.”

5. I think there are two such lines in my file, so be sure and check yours also to ensure you’ve got them all. You’ll know by nighttime, or whenever your job runs whether we were successful.

Also check out:

The Bacula Messages Resource

Fixing Amarok’s Collection Database

The latest version of X Windows (Xorg) really wants to use something called hardware abstraction layer to handle devices, but I’m experiencing some side effects.  For example,  enabling  Hardware Abstraction Layer Daemon (hald) caused my music player (Amarok) to lose all its song collection information.  I sure didn’t want to have to re-rate all those songs and lose all the other  song play and similar artists info.  It’s not life or death, but no sense to lose it.

It turns out there’s a pretty elegant fix to retain all your song information even after installing hald.  I think this would also work in the less specific case where you moved your music from one location to another.

1. Fully rescan the collection in Amarok. (tools, rescan collection).  Close Amarok.

2. Open the mysql console on the command line, using
mysql -u root -p

3. Issue the following commands at the mysql prompts
mysql>use amarokdb;
mysql>delete from tags;
mysql>quit;

Then, restart Amarok, and rescan the collection.

Credit for this solution goes to Max Kossick: Original post.

The technical description:
Checking out the devices table in MySQL, I noticed Amarok sees hard drives (and probably other devices) differently now that hal is running.

Before hald, Amarok saw the drives like: /org/kde/mediamanager/fstab/devad0s1a
After hald, it’s more like: /org/freedesktop/Hal/devices/volume_uuid_0AA3_32DF

So the solution was to empty the tags table.  My guess is that during the rescan, Amarok then notices there aren’t any tags in its collection database for all these files, and re-updates the tags.  While looking at the files, it notices, hey – those are in new locations now.   (The deviceid is a foreign key to the devices table.)

If you’re morbidly curious about the Amarok collection table structure, there’s a diagram here: Amarok Table Structure

If for some reason, you don’t trust the easy solution, you can meticulously update deviceID for each table where it’s listed.  This solution borrows extremely heavily from Max’s original post (credit for this portion goes to Seb Ruiz).

mysql> use amarokdb;
mysql> UPDATE embed SET deviceid=B WHERE deviceid=A;
mysql> UPDATE images SET deviceid=B WHERE deviceid=A;
mysql> UPDATE labels SET deviceid=B WHERE deviceid=A;
mysql> UPDATE lyrics SET deviceid=B WHERE deviceid=A;
mysql> UPDATE playlists SET deviceid=B WHERE deviceid=A;
mysql> UPDATE statistics SET deviceid=B WHERE deviceid=A;
mysql> UPDATE tags SET deviceid=B WHERE deviceid=A;
mysql> UPDATE tags_labels SET deviceid=B WHERE deviceid=A;
mysql> UPDATE uniqueid SET deviceid=B WHERE deviceid=A;

You can figure out what values to use for deviceid (instead of A and B)
by doing the following:
mysql>select distinct deviceid from tags;

That's all for now.
Scott

Updating BIOS in FreeBSD (without Windows or a floppy drive)

I had strange happenings with the server, and figured a bios version upgrade might help out. After all, I was using a newer processor on an older motherboard, with newer ram. The BIOS version I had was A02, where the latest version was A10.

Most BIOS manufacturers provide free updates to patch their BIOS code. Unfortunately, often times these updates are:

  • Designed for Windows – i.e. they include “dummy” – type updaters for users who don’t know how to use a boot disk.
  • Designed for machines with floppy drives. Who uses floppy drives – what is this, 1985? Why not make me boot off punch cards or something?

Anyway, there are several ways around these two issues; like most modern low-level PC troubleshooting, a CD-based boot disk is involved.

Ingredients:

One DOS boot disk iso file – FreeDOS works pretty well. I used this one: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdbasecd.iso but any of the iso-based ones ought to work OK.

One PC running your favorite OS, FreeBSD.

Working installation of cdrtools (installable from /usr/ports/sysutils/cdrtools). To check if you already have this, you can try typing “which mkisofs” on the FreeBSD command line. If you get a “Command not found,” you need to install it. If it comes back telling you where it’s located (e.g. /usr/local/bin/mkisofs, lucky you – you have it.

You’ll need the standalone executable for your BIOS upgrade… For my Dell, this was located on Dell’s support site. What you’re looking for is just the executable file that does the actual BIOS update. You may have to hunt around a little or find a way to extract the .exe from your manufacturer’s disk image. Some of the images available are self-extracting exes. Again, the one you want is just the executable dos-based updater.

Procedure:

What we want to do is edit the FreeDOS ISO image file to add the BIOS manufacturer’s executable file, then burn that new CD. Easy enough? You’d think so – but actually this is much easier on FreeBSD than you might think, and you don’t need expensive software to make it happen.

Here’s how:

Get your BIOS upgrade and your FreeDOS CD image (ISO) onto the FreeBSD computer.
I did this by using the fetch command, for example:
#fetch http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdbasecd.iso

Mount your FreeDOS ISO file: this will allow you to access all the FreeDOS files:
First, we need to create a device node in /dev

#mdconfig –a –t vnode –f iso_filename.iso –u 0

Next, we mount our newly created device:
#mount_cd9660 /dev/iso9660/FreeDOS\ 1.0 /mnt/freedos

Note that in the example above, I called the iso file iso_filename.iso, and mounted it to /mnt/freedos. You will of course have to create whatever directory you want to mount to ahead of time. No problem, right?

Great, so now, we can browse that ISO if we want to, just to check it out:

#cd /mnt/freedos
#ls

Now, I have an autorun.inf file, boot.catalog, freedos, isolinux, and setup.bat.
OK. One thing about our mounted ISO is it’s read-only, so in order to add more to it, we can just copy it to another directory (I used /tmp/bios_cd). Maybe there is a way to mount the ISO so it’s not read-only, but it seemed easier just to copy to a temporary location:

#cp –R /mnt/freedos /tmp/bios_cd

So now we can add our bios executable to the directory, create a new iso image, and burn it to disc.

#mkisofs -o /tmp/freedos_biosupdate.iso -q -l -N \

-boot-info-table -iso-level 4 -no-emul-boot \

-b isolinux/isolinux.bin \

-publisher “FreeDOS – www.freedos.org” \

-A “FreeDOS beta9 Distribution” -V FDOS_BETA9 -v .

Those commands will give us our new iso file, “/tmp/freedos_biosupdate.iso”
Note that the period at the end of the mkisofs command is required.

Pages that helped:

Mkisofs procedure graciously provided from this site: http://www.tummy.com/journals/entries/jafo_20080920_234755

Image mounting info for FreeBSD from here:
http://www.bsdguides.org/guides/freebsd/beginners/mdconfig_mount_images

This ended up working great, with one minor snag: as mentioned on the tummy.com page, I did have to escape out of the SETUP procedure for FreeDOS to avoid having it install FreeDOS as my OS on the hard drive. Why this is the default for FreeDOS, I have no idea. In retrospect, it may have been easier just to attach a floppy drive, but this worked out, and I didn’t have to order software.

Sendmail on FreeBSD in a jail with masquerading

Today, I wanted to set up a sendmail server to let the server send mail out.  The uses of this are many – I’m thinking it’d be helpful for situations like WordPress or Joomla where a user might need a password-reset from time to time, or if I’m posting resumes and a recruiter might like it if I’ve got email coming from my own domain instead of from gmail.

The ingredients:
Sendmail (was included already in my FreeBSD distro)
One complete Jail (was created earlier on) – not really a neccessity – more a nice to have for security purposes.

Procedure (what I did to make it work):
Well, like most installations, there was a lot of futzing around with the configuration to whip Sendmail into shape.  Apparently Sendmail is notorious for its byzantine configuration system. A lot of people really seem to like postfix or exim.  I decided to stay with Sendmail:

1. Make sure sendmail_enable=”YES”
exists in the /etc/rc.conf file.

2. edit your sendmail configuration file.  Most sites, and even books are kind of wishy-washy about this – a lot of them (for example FreeBSD handbook Chapter 29, and Absolute FreeBSD 2nd edition), just pass the issue off as being “beyond their scope.”  This is  a nice way of saying they have no idea what they did to get it working back when they did, and you should just use postfix or ISP’s server or something.  Anyway, how you edit your /etc/mail/hostname.mc file is really dependent on what you want your Sendmail server to do.  Believe me, it is possible for you to get Sendmail working.  It’s not that hard, especially with FreeBSD.

My configuration:
Well, like most folks these days I’ve got a firewall that uses NAT (network address translation).  I do not have a static IP address through my ISP.  I am using DynDNS to handle that stuff.  Also, it seemed like way overkill (and was confusing with the jail involved) to set up BIND internally to get my three computers to talk to one another by name, much less to the rest of the world.  Far easier just to use the hosts file in /etc/ for that.

The problem:
I tried sending email from my server to my gmail address using mutt, and the source address was always including the machine name.  In other words, the email was coming from scott@jail.scottspare.com and not from scott@scottspare.com.  Googling around, this sounded like a problem a lot of people have, but the documentation was pretty un-helpful.

The first set of suggestions involved adding something like this to the domainname.mc file in /etc/mail:
MASQUERADE_AS(`scottspare.com’)
MASQUERADE_DOMAIN(`scottspare.com’)
FEATURE(`masquerade_entire_domain’)
FEATURE(`masquerade_envelope’)
FEATURE(`allmasquerade’)
FEATURE(`use_cw_file’)

Note that some people around google add “dnl” to the end of all these lines, but I didn’t – I just made sure that no spaces or anything were at the end of the lines.  I guess dnl is sendmail’s way of handling comments.  No wonder people think it’s weird.

Anyway, in FreeBSD to make your configurations stick, after you edit and save these  .mc  files, you need to run the following as root from your /etc/mail directory:
make
make install
make restart

this creates the new .cf files named after your host in the /etc/mail directory,  installs them, and restarts the sendmail server, respectively.  More information on that procedure is located in the freebsd handbook.

So according to most sites out there, you should be all set, right?  Your hostname or machine name should not appear in your emails anymore, correct?  Well, that’s what I thought too – but I was wrong.  In order to actually get it working, I had to remove the following line from domainname.cf file.  (I know that everyone says never to edit domainname.cf, but this worked for me.)

I commented out a line that said C{E}root from my domainname.cf file by adding a # in front of it, and that made it work.  I think that line is telling sendmail to append the machine name on emails coming from root.  Why that’s the default I have no clue.    Now when I send emails from mutt, they come from user@scottspare.com, not from user@host.scottspare.com.  It’s great.

Other stuff: I had to tell my firewall to allow port forwarding on port 25.  That’s required so the machine can receive mail back to the domain.  If you only want to send and not receive, you probably can ignore that.

Some websites that helped me out:
Freebsd sendmail handbook article
Sendmail’s page on masquerading syntax (didn’t help that much)
This page from HP which was really confusing and obscure, but helped anyway.

And, to be able to read my email from the non-jailed server using mutt, I had to edit .muttrc outside the jail to tell it to point to the jail’s mail folder.  This is under mailboxes if I remember correctly.  You can start mutt using “mutt -y” to get a list of your mailboxes.

At one point, I realized that the MTA setting was not defined in DYNDNS.  Actually, I had tried earlier to tell DYNDNS about the actual hostname of my mail server, but even after exposing the BIND server I’d set up to the internet by allowing port forwarding on the router on port 53 to my server’s ip address, DYNDNS just didn’t seem to want to do it.  So I turned wildcard on, opened port 25 (for sendmail), entered just the hostname under the MTA field in DYNDNS, and it works.

It’s possible and likely there’s a better way to do it all.  I welcome comments.
Next steps on this one: I’ll attempt to set it up so I only need to run one sendmail server for the network.  Also a dovecot server for IMAP.

Until next time,

Scott

 
  • jacob: Thanks for a great post. I had one issue with your command: #nice -n 10 portupgrade -aRr. you will get...
  • Pan: Do you have any problem printing from a windows machine? I have an Samsung ML1610 and I can print once from...
  • Scott: One other item. CUPS. To get this working right, I edited /usr/local/etc/cups/cupsd.conf , and added the line...
  • Scott: Follow-up item: after disabling nmbd as the Section 6 wiki mentioned, I found that I could no longer access...
  • Scott: Dan, that’s a great point. I experienced exactly what you’re saying today when I realized...