FreeBSD - a lesson in poor defaults

fdm is not an MTA. It connects to remote IMAP or POP3 servers and fetches mail, then sorts it into a local mailbox. It's used in conjunction with MUAs like Mutt, Alpine, and Thunderbird.

But if you have a use for it then yes, it is pretty good, albeit with a steep learning curve. ;)
 
You guys shouldn't assume that, as users, your needs are the same as corporations, ISPs, server farms, etc.

I think that this is an important consideration. FreeBSD doesn't pretend now to be a "Windows replacement" O/S. I don't know how well PC-BSD works for that. The guys I know who are doing Windows replacement consumer installs are current talking Mint, after having talked up Ubuntu and Mepis.

My needs are "the same as corporations, ISPs, server farms etc." but without a large user base. To get down to brass tacks, I think there are two questions that need to be answered:

1. Should an O/S rely on its security resources to run "bare" on an outside network, without a hardware appliance between it and the outside? I've experimented with that, and while it's a chore, it's risky. Problem for the SOHO user is that a really good small security appliance isn't well-supported by the consumer device market. I use Fortinet Fortigate 60's, which are not cheap, and overkill for my needs---but they do a real job at blocking the script kiddies.

While setting up a Fortigate to protect a Windows system is fairly quick and simple, the moment you start adding an MTA and an HTTP server, you've got to get an appropriate configuration. Some of the needed resources require command-line programming.
Not sure about the current Cisco ASA's, but I think that they also require a lot of command-line configuration.

2. How much is it reasonable to expect a "systems administrator" to do in O/S configuration? When I read the Mailman support mail lists and a few other places, I get the impression that many people employed as "systems administrators" expect to install pre-built binaries and use point-and-click GUI tools.

For the past 15 years, since I retired, I've only worked with a few O/S's---primarily, Solaris---although I have looked at some of the Linux distributions rather cursorily.
For the 20 years before that, I worked with both BSD and System V systems at kernel level, so my "systems administration" skills add up to "as deep as you need to go" to get something to work.

I think that so far as the current FreeBSD default sendmail goes, it works out of the box. And I like getting the reports on a local mail spool, as they can be dealt with individually with a simple mail reader like mutt. Boosting up the configuration to work as a incoming/outgoing MTA is, for the most part, adding
adding about 10 command lines to the master .mc that builds sendmail.cf, primarily to handle masquerading and dnsbl spam filtering. I don't do sendmail.cfr vi fixups.
 
I think that so far as the current FreeBSD default sendmail goes, it works out of the box.
As I recall, without a FQDN it will give errors on bootup. So no, it still doesn't quite work out of the box.
 
My needs are "the same as corporations, ISPs, server farms etc." but without a large user base. To get down to brass tacks, I think there are two questions that need to be answered:

1. Should an O/S rely on its security resources to run "bare" on an outside network, without a hardware appliance between it and the outside? I've experimented with that, and while it's a chore, it's risky. Problem for the SOHO user is that a really good small security appliance isn't well-supported by the consumer device market. I use Fortinet Fortigate 60's, which are not cheap, and overkill for my needs---but they do a real job at blocking the script kiddies.

While setting up a Fortigate to protect a Windows system is fairly quick and simple, the moment you start adding an MTA and an HTTP server, you've got to get an appropriate configuration. Some of the needed resources require command-line programming.
Not sure about the current Cisco ASA's, but I think that they also require a lot of command-line configuration.

2. How much is it reasonable to expect a "systems administrator" to do in O/S configuration? When I read the Mailman support mail lists and a few other places, I get the impression that many people employed as "systems administrators" expect to install pre-built binaries and use point-and-click GUI tools.

I am not sure that the questions raised were addressed.

The OpenBSD project works well as network security appliance. An example setup is here. (The linked OpenBSD manual pages broke last week and have yet to be fixed). jggimi has been very accessible in that forum often sharing his config files and helping others trouble shoot theirs. Oko, systemadmin in an academic settings, diagrammed his home network topology in this post. If you are paying Fortigate a significant amount you may want to look into setting up your own firewall/NAS. You might also want to look at opensmtpd which is now the default mail server in OpenBSD. opensmtpd does not do everything but it does meet many peoples needs with simplicity and elegance.
 
I agree that OpenSSL should be exiled from base, specially now that we have much better solutions
+1

I also agree that we are drifting toward a new topic and it would be a great topic. Not a chest-thumping thread but rather one that summarizes the strengths and weakness of OpenSSL/LibreSSL, sendmail/opensmtpd, ?????/OpenSSH, ntp/opentpd, firewalls/pf ....
 
I agree that OpenSSL should be exiled from base, specially now that we have much better solutions. But things are done for a reason and some of the other points seem a lot like "Why is FreeBSD not OpenBSD?".

I agree but how to actually do it? There are many many utilities in base that absolutely need SSL/TLS support out of the box such as fetch(1). Ideally you would just pkg install openssl/libressl as the first step in a freshly installed system to get those working but as it happens pkg(8) itself relies on SSL/TLS...
 
Ideally you would just pkg install openssl/libressl as the first step in a freshly installed system to get those working but as it happens pkg(8)itself relies on SSL/TLS...

Any operating system absolutely needs an SSL/TLS library out of the box. The question is whether there's a better choice than what FreeBSD is currently using that makes it worth changing the software in base. Using LibreSSL definitely makes some sense, although at this point I don't know how many issues switching the default would cause (could be quite a lot, especially if you include packages that use ssl).

Same with Sendmail. I would never suggest having no built-in email functionality at all, but to me it makes much more sense to provide Sendmail as a package, and just have a minimal SMTP client and local delivery agent in base.
 
Same with Sendmail. I would never suggest having no built-in email functionality at all, but to me it makes much more sense to provide Sendmail as a package, and just have a minimal SMTP client and local delivery agent in base.

That would be great. Or even just fix the Sendmail dependency on a FQDN.
 
Sendmail dependency on a FQDN.

This is not true. Sendmail only depends on hostname that resolves to an address, any address. The hostname can be just joe and as long as that name resolves to an address through the resolver(3) Sendmail is happy. All MTAs have the same basic requirement, even the most minimal ones. They need to know the name of the system they are running on to properly fill in the header values in emails.
 
This is not true. Sendmail only depends on hostname that resolves to an address, any address. The hostname can be just joe and as long as that name resolves to an address through the resolver(3) Sendmail is happy. All MTAs have the same basic requirement, even the most minimal ones. They need to know the name of the system they are running on to properly fill in the header values in emails.
Thanks kpa. I'll defer to your better knowledge. It has been a little while since I did an install, but I could have sworn I was getting an error message at boot when I only had a single name, and that adding a full name solved that. In fact it would stop and wait for a timeout before continuing.
 
I agree but how to actually do it? There are many many utilities in base that absolutely need SSL/TLS support out of the box such as fetch(1).

Of course, I wasn't sugesting that we remove ALL SSL/TLS libraries from base. I was suggesting replacing OpenSSL with LibreSSL (or with Boring for that matter). While I must admit that I was, for the most part ignorant to the terrible status of OpenSSL as a codebase, now that my eyes are opened I believe something should be done about it. IMO the project should adopt as an official stance the removal of OpenSSL and its replacement with a more suitable library. I do not trust OpenSSL code anymore and I don't want it running on my productions servers.

Ideally you would just pkg install openssl/libressl as the first step in a freshly installed system to get those working but as it happens pkg(8) itself relies on SSL/TLS...

I believe there is a way to do so. Bernard Spil was (is AFAIK) working on it . I understand the solution to this is to patch the base system to build with LibreSSL (1) and making SSL in base private(2). 1 Is more or less working. 2 is harder to do, but with packaged base coming to 11 it should not be impossible. There is a way to do it, it just needs significant momentum to acomplish.

Sendmail is an easier solution, but the person working on replacing it with DMA ran out of time IIRC (I don't really know what needed to be done, last time I checked out a -CURRENT image and tried to build the source, DMA didn't build).
 
Hm, looking at the PkgBase wiki entry, you can read about these "kinks", and the impression is that, yes, it's alive, but just a little bit ;).

The "src" tree can build packages now for a long time, and I don't think this will ever be removed again. But whether it will ever be officially supported? I'm not sure. I personally think it's a very nice idea, but looking at all the problems to solve, I'm a bit unsure it's really worth it. We will see.
 
Hm, looking at the PkgBase wiki entry, you can read about these "kinks", and the impression is that, yes, it's alive, but just a little bit ;).
Yes, saw this. Along with these links:



After discussing with the team, we're going to go ahead and abandon this revision. While we wanted to see something usable happen in this space, it's just not cost or time effective to spend far more effort fighting politics than the actual implementation took. We will continue using a non-package solution for our products for the future.

The disturbing phrase there is "fighting politics".
 
The disturbing phrase there is "fighting politics".
This is not PkgBase, it was an attempt to "integrate" base into ports. There are good reasons not to do this (and probably other good reasons why it was attempted as well). Talking about "politics" is nothing but a code for not accepting the counter arguments.
 
Back
Top