Richard T's questions

This environment has twins of virtually everything, including two web server / firewall / gateway systems, and they were getting long-in-the-tooth version wise, so I decided to upgrade from Fedora Server 30 to 38 on one of them. The idea was, of course, to bring both "into the modern era", but one at a time.

My timing was curious because at the very same time I began the upgrade, without even touching (physically or electronically) the other server, it decided to fail! So, now I have a "server down" scenario. -ugh- Unfortunately, this also means I don't have a working example to look at.

The one I didn't touch apparently has hardware issues and I can't address them right now, so I'm focused on the one I already started, which has now emerged from the upgrade / update to Fedora Server 38 just fine... EXCEPT for the fact that it has an issue where it's not serving as an actual gateway! ACK!

To be clear, FROM it you can access the internet and internal nets just fine. But it's not passing bits THROUGH it.

Of course, it's all generic Fedora Server (Fedora Core 38 with whatever tweaks the Server version gets) and whatever differences there are between 30 and 38 are likely substantial, though here all that matters is the networking.

It's got two NICs, and I configured them as was (that is, IP addresses, masks, etc), and in fact the installation process seemed to help by helping identify which NIC was internal and which external. I used my past experience and was pretty sure I'd done it correctly.

Indeed, once up I was instantly able to get to the box via ssh via the internal net. And, well, there's a lot to do on such a system but soon enough I got to the firewall aspects of it all. (At that point I didn't realize the other system was not-responsive.)

The first thing I did was move the interfaces to internal and external zones, and then turn on masquerading on the external zone. I forwarded mail through, and so forth, using the forward-port commands, etc, and ended up with the external looking like this:

# firewall-cmd --zone=external --list-all
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources:
  services: http https ssh
  ports:
  protocols:
  forward: yes
  masquerade: yes
  forward-ports:
        port=25:proto=tcp:toport=25:toaddr=192.168.1.1
  source-ports:
  icmp-blocks:
  rich rules:

The other, internal:

# firewall-cmd --zone=internal --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources:
  services: dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

As an aside, I didn't add any of the services to the internal zone - they're apparently just defaults, I guess.

I spent PLENTY of time with the routing as it looked pretty screwy to me from the start. However, it's now this:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router           0.0.0.0         UG    100    0        0 enp1s0
router           0.0.0.0         255.255.255.255 UH    100    0        0 enp1s0
192.168.1.1     0.0.0.0         255.255.255.0   U     101    0        0 enp2s0
192.168.1.1     0.0.0.0         255.255.255.0   U     101    0        0 enp2s0

FYI, this version of Fedora doesn't use IP Tables but rather Network Manager - a toolset I've loathed from the first, but now seems more mature. And anyway, MOST of the materials to be found on the net speak of this older strategy and is of no help. However, this page points people in the right general direction.

UPDATE 1

I got the older hardware that had apparently failed back up. It wasn't that hard to do, but it increases our odds. ...And I say "our", because a colleague has joined me in the fray; he's focused on the older box, and I'm focused on the newer one.

NEITHER is passing bits through as a gateway / firewall, and that puzzled me. However my colleague reminds that the one system was already not really working right, likely due to a botched attempt to get a particular OpenVPN installation going. And since he did that work, well, he's going to continue there.

This HAS to be something simple; what basic fundamental is being overlooked?!

This server system has been serving email services since Red Hat v 1.1 (circa 1997 I think) and now is on Fedora Core 37; through many hardware and OS updates along the way it has been kept current. And, we chose postfix and dovecot early on, and are still using them. And I've been the system mangler all this time.

A week ago tomorrow we had our /var tree wiped out due to a bug in a backup script - doah! And it required a full rebuild of the OS, "from scratch", to the same version. All the software not included in the Fedora Server 37 distribution was loaded fresh via dnf install. And, we got our full config back from our good backups.

On Monday, two days ago, I noticed the system was noticeably sluggish but didn't have time to look into it. And I also noticed our link to the internet seemed to have performance problems. That was a clue...

Then, I decided to get spamassassin working again - it takes time to configure a mature environment like this! And SA had been disabled before the loss of /var, so it didn't just start back up. And anyway, when I went to check /etc/var/log/maillog to see if it was doing its job, I found all these mail being relayed messages?! Whisky Tango Foxtrot?!

I then checked the mail queues - hundreds of thousand to Gmail alone! WOW!

For now, I've turned off ALL outbound emails with:

default_transport = error: Sorry spammers, we're not sending your email! So sue us!

And began trying to figure out what went wrong.

I DID find SOME were getting through claiming to be 127.0.0.1, so I closed that down. And I methodically went through all the various (and copious) postfix configuration options and couldn't find a thing wrong...

So, I went to use one of these script-testing open-relay testing web sites that try a dozen or so different hacks that spammers use to convince otherwise well-configured servers to relay their mail, but I couldn't find any - the last time I looked, there were a half-dozen or so such web sites! (What happened to 'em?! If you know of one, please tell me!)

And so I used nmap. It does NOT do a comprehensive job, or if it can, I'm not familiar with how. But I turned to send back on and tested. In testing, it says:

Host is up (0.00027s latency).
rDNS record for <ip-addr>: <reverse-lookup-map>

PORT    STATE    SERVICE
25/tcp  open     smtp
|_smtp-open-relay: Server doesn't seem to be an open relay, all tests failed
465/tcp filtered smtps
587/tcp open     submission
|_smtp-open-relay: Server isn't an open relay, authentication needed
MAC Address: [its mac address] (controller's mfg name)

Nmap done: 1 IP address (1 host up) scanned in 22.03 seconds

The ONLY two websites I could find to look at it and report were non-responsive - the one loaded but didn't respond and then when I tried reloading the page, it wouldn't reload, and the second kept saying it was busy, try again later.

So ... back to figuring it out "by hand."

OK, so NOW what do we do?

ALL requests for setting information will be gladly honored, but the config file is first of all huge, and secondly it contains a lot of private information we don't want out there.

More information - at anx's request, the output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
compatibility_level = 3.6
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 10
debug_peer_list = <past-not-current-external-ip>
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5
default_transport = error: <our-middle-finger-to-spammers>
disable_vrfy_command = yes
html_directory = no
inet_interfaces = all
inet_protocols = all
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_size_limit = 1073741824
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 536870912
meta_directory = /etc/postfix
milter_default_action = accept
mydestination = $myhostname, localhost.$mydomain, localhost, <list-of-60ish-domain-names>
mydomain = <primary-domain>
myhostname = mail.<primary-domain>
mynetworks = <list-of-5-internal-ips>
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
proxy_interfaces = <a-non-extant-external-ip-we-used-to-have>
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
relay_domains = $mydestination, <list-of-11-internal-ips-most-don't-exist-now>
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_access, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, check_sender_access hash:/etc/postfix/sender_access, check_client_access hash:/etc/postfix/pop-before-smtp, permit_mynetworks
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/pop-before-smtp, reject_non_fqdn_sender, reject_unknown_sender_domain
smtpd_tls_cert_file = /etc/letsencrypt/live/<primary-domain-name>/fullchain.pem
smtpd_tls_dh1024_param_file = $config_directory/dh2048.pem
smtpd_tls_dh512_param_file = $config_directory/dh512.pem
smtpd_tls_key_file = /etc/letsencrypt/live/<primary-domain-name>/privkey.pem
smtpd_tls_security_level = may
soft_bounce = no
strict_mailbox_ownership = no
unknown_local_recipient_reject_code = 550

More information - most also at the request of anx:

• Postfix uses ports 25 (smtp) and 587 (submission or msa).

• Dovecot uses ports 993 (imaps) and 995 (pop3s) while it listens on 143 & 110 (imap / pop) which are blocked by (multiple) firewalls.

  postconf -M

  smtp inet n - n - - smtpd

  submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes

  pickup unix n - n 60 1 pickup

  cleanup unix n - n - 0 cleanup

  qmgr unix n - n 300 1 qmgr

  tlsmgr unix - - n 1000? 1 tlsmgr

  rewrite unix - - n - - trivial-rewrite

  bounce unix - - n - 0 bounce

  defer unix - - n - 0 bounce

  trace unix - - n - 0 bounce

  verify unix - - n - 1 verify

  flush unix n - n 1000? 0 flush

  proxymap unix - - n - - proxymap

  proxywrite unix - - n - 1 proxymap

  smtp unix - - n - - smtp

  relay unix - - n - - smtp -o syslog_name=postfix/$service_name

  showq unix n - n - - showq

  error unix - - n - - error

  retry unix - - n - - error

  discard unix - - n - - discard

  local unix - n n - - local

  virtual unix - n n - - virtual

  lmtp unix - - n - - lmtp

  anvil unix - - n - 1 anvil

  scache unix - - n - 1 scache

  postlog unix-dgram n - n - 1 postlogd

Information yet to fetch:

• What's in the "locally added received header"s.
• Analysis of postfix log "stack" for a given queue ID.

HOLD THE PROGRAM!

Simply HAVING to send a few vital emails out, but not wanting to give the spammers a single use of our systems, I decided to try just turning off dovecot... I found that turning off dovecot and restoring the default_transport setting allowed outbound to work normally and Postfix did NOT become an open relay! YAY!

SURE, it won't work for our non-local users (which number > 1 and < 100), but hey, "you gotta do what you gotta do..."

I think this shifts the focus considerably; dovecot is THE issue.

This is on Fedora Core 35: This environment is mature and has a few systems that are called either firewalls or gateways, and for the first time, we want to do an NFS share to one of these systems.

After having trouble with the mount on the client, I proved the server's config is fine by doing an identical mount on a different internal system using copy-paste of the /etc/fstab entry. I figured it had to be a firewall issue, so I changed the interface to be in the "trusted" zone. And yet I still get:

mount.nfs: access denied by server while mounting 192.168.1.1:/fu

So, I did some research and figured out to do:

rpcdebug -m nfsd -s all

But I get nothing related to the mount in question - in fact NOTHING goes into /var/log/messages ... isn't that where I'm supposed to look?! (Other nfs related items are going there, but not this mount.)

So, I tried our backup server and got the same (null) result. And I also tried changing from using the hostname and using the IP address on the client - same results either way, nothing but what I've reported.)

It recently became painfully obvious that I just don't know how I'm supposed to manage Python packages on my systems.

I simply MUST be able to know what all is installed and under what user IDs, since the Python community is coached that nothing should be installed as Root. . . . This leaves me with a serious problem!

In this instance, I'm using Fedora distributions, MOSTLY but not exclusively Fedora Server (all some form of Fedora Core) BUT, the question applies for other distributions, too, I'm sure.

Ultimately, the question is; how is a system manager supposed to deal with this PROPERLY?

Do note that I'm NOT asking about how to install Python itself, and I'm not talking about a development system, where if the developers screw up their own system, well, it only affects THEM, though that's still not great.

What I'm focused on is that SOME packages of software that use Python have their own sub-packages that aren't available via the usual platform package installation paradigm. And it was one of these that prompted this sudden discovery of the risk I have; Mailman3 is just such a package as installing it didn't also install all the needed sub-packages, so there were then some "pip install"s needed for those. And on discussing it with a colleague, he admitted screwing up a system that I am responsible for managing, only to learn he screwed it up via a Python package he pip installed...

...I feel like I may be forced to implement security so individual users CANNOT install Python packages and thus increase my own workload, not only to do that, but then to install packages they want FOR them and all the hassles that entails. I'm hoping I'm just clueless about some "feature" of Python! Otherwise, I think Python needs a serious re-think about how it does what it does as it surely appears to be very unfriendly for the system manager(s).

After walking down the garden path of reading the documentation, and being led astray - in particular, by the materials I found here - out of pure frustration I eventually found my way to the "official Wiki", which is here, and it pointed me to the "missing" Command Line Interface (CLI) utilities. They're found, on my installation, at /lib/mailman/bin. However, they don't work!

For example, running as user mailman:

$ add_members -h
Traceback (most recent call last):
  File "/lib/mailman/bin/add_members", line 89, in <module>
    from Mailman import i18n
ImportError: No module named Mailman

I'm sure someone will ask, so:

Fedora Server 32 running mailman3-3.2.2-1.fc32.noarch ...And some 153 or so Python3 packages... A python3 --version command says it's 3.8.5.

BTW, I used DNF to install Mailman3. I have no idea if I was supposed to install more than just that, but normally DNF will complain if there are unresolved dependencies and it didn't complain.

...I really need to get these working and am NOT a Python programmer, by any means. Nor do I really want to take the time to learn it now... Why mention that? Keep reading:

As a "bread-crumb" (as in the Hansel and Gretel folk tale) for those who might follow along later, from the documentation at the previously cited site, APPARENTLY, again, according to THAT source, you have to get into a Python shell, write your own Python functions and, in short, become a Python AND Mailman library expert just to use what they call a CLI interface. Crazy!

If going that route, you su to mailman (to get the right user context) then:

$ PYTHONSTARTUP= mailman3 shell

And you get a python prompt >>> and from there you have to do things like:

>>> from mailman.testing.documentation import cli
>>> command = cli('mailman.commands.cli_withlist.shell')
>>> command('mailman shell --details')

And, there's a LOT possible from here, All of which requires a lot of typing AND knowing Python far better than I presently do. There's documentation for this over here. ...All I really want to do is import a file containing people's names and email addresses saved from the previous version and add them to a list, but it's a LOT of typing to do that in this environment.

Happily, that all DOES work, best I could tell from my not-fully-informed attempts at trying it.

It should be "very easy" to write scripts that would emulate the older mailman 2.x utilities, so perhaps you can see how I was frustrated before I found the utilities STILL DO exist, they just don't work! ...I'm 100% sure I could learn Python and the mailman3 library and write my own, but I have no time for that. ...SO, I need to get these other utilities working.

I did upgrade on a Fedora Server and was SHOCKED to discover thousands of root attacks on my publicly facing servers and I can't seem to figure out how to stop them!

To be clear; It IS possible to log in to the root account with a password when it should not be possible and the "root attacks" are crackers trying to do just that.

Involved, or possibly involved, Packages are:

Fedora Server 32 openssh-server-8.3p1-3.fc32.x86_64 pam-1.3.1-26.fc32.x86_64 fprintd-pam-1.90.1-1.fc32.x86_64 pam_afs_session-2.6-12.fc32.x86_64 gnome-keyring-pam-3.36.0-1.fc32.x86_64 systemd-pam-245.8-2.fc32.x86_64 pam_passwdqc-1.4.0-1.fc32.x86_64

... I'm not really sure what the older stuff was, but not older than FC27, that's for sure, and probably a lot younger.

I had been relying upon:

PermitRootLogin prohibit-password

Before that, it was without-password, and both seemed to still work until this change.

Note that the following comment in the default sshd_config file seemed to me to be spurious as the PermitRootLogin parameter was honored, but APPARENTLY it was intended as a warning about UsePAM changing in the future and we should prepare. Well, now - and I'm guessing here! - it has become the actual forced-upon-us setting:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# WARNING: 'UsePAM no' is not supported in Fedora and may cause several
# problems.

PLEASE NOTE the bit about UsePam no not being supported on Fedora!

The result of this change, as stated above, was that now I have root attacks. I am NOT using PAM, and DO NOT WANT to use PAM, so, to use an old-fashioned expression, "this burns my bottom."

However, I TRIED setting the "PAM configuration" I don't even want but it didn't work. I tried this:

UsePAM yes
PasswordAuthentication no
ChallengeResponseAuthentication no

This is exactly what the comment appears to ask us to do, but it doesn't work.

By the way, I DO REQUIRE password authentication for some accounts.

So, I tried an explicit UsePAM no, even though I haven't a clue what "several problems" this "may cause." (Any comments about what those problems are would be very welcome.) However, UsePAM no doesn't work, either!

On the one hand, I can't turn off ssh as this functionality is required, and, by the way, root access is required, too, for some remote backup functionality that spans many accounts, but I also cannot allow a root crack! This is a DISASTER!

Does anyone have a minimalistic PAM setup that can let someone like me keep going without undue delay? ...Or, if I have to go through a full PAM setup, can someone point me to a good tutorial or some such? I really don't have time to learn about a system I don't want!

It might be worth mentioning that other than discussed in this question, there are NO modifications to the sshd configuration from stock OTHER THAN the PermitRootLogin attribute and the three PAM related lines above this that were tried temporarily.

NEW DATA

I discovered that of the many servers I updated last Friday, ONLY ONE of them appears to have this problem! All the rest are on the SAME O/S version.

One key difference I discovered is that on the one that's got the problem, there's NOTHING going into /var/log/secure since the update!

NEW DATA II

It turned out the log file problem was related to SELinux. Once fixed, /var/log/secure was being written to again, but it didn't fix the problem of still being able to log in to root via password when it should not be allowed.

Hmmm...

My environment, happily functioning for a long time, experienced a power outage - of course, the immortal power supply was offline at the time, needing new batteries. As the administrator, I know there hadn't been any updates in some time and there were no administrative tasks going on at the time. And, I know it was fully healthy, having just gotten a replacement motherboard and then having been fully checked-out before being returned to service. (Oh, it also has ECC memory.)

Following reboot when the power came back, all systems rebooted promptly but the backup server appeared to not have run the cron @reboot job that mounts disks between it and the primary.

Investigating, there was no obvious reason why the job didn't run, so I went to look at the email that's supposed to be sent - to root in this case. So, I launched Alpine which I use for this and there was no alpine?! Confused, I figure I somehow forgot to install Alpine, so I ran $ dnf install alpine ... that should do it, but it instantly returned without giving the familiar "Last metadata expiration check" stuff. That's what told me something substantial must have happened. ...I tried it on the working server and it seems healthy.

So, I tried yum with the same it_didn't_do_anything result.

So, I looked at the files. The launcher for dnf is identical to the one on my not-damaged server.

The launcher is python, so I went looking for a way to confirm python itself is OK, and it launches and runs gnome-music just fine, so I suspect something went wrong with the yum & dnf specific python libraries.

I found the rpm files still on my box in /var/cache, but when I try and reinstall with rpm, everything I've tried so far fails with dependency issues, including constructs like $ rpm -Uvh -p /var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-*.rpm

Here are the rpm files:

/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-plugins-core-4.0.18-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-dnf-plugins-core-4.0.18-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-libdnf-0.55.2-1.fc32.x86_64.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/python3-dnf-4.5.2-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/libdnf-0.55.2-1.fc32.x86_64.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-data-4.5.2-1.fc32.noarch.rpm
/var/cache/PackageKit/32/metadata/updates-32-x86_64/packages/dnf-4.5.2-1.fc32.noarch.rpm

Obviously this is a Fedora Core 32 installation. ...I think MAYBE I could get my way out of this if I only knew how to tell rpm to reinstall all these packages - maybe I'm just doing it wrong!

Any help appreciated.

(Note this was errantly posted on Stack Exchange when I should have put it here - I don't have the privs either here or there, as I do on Stack Overflow, to migrate between venues.)

Background

I've been the administrator since inception of this 24-ish year old site which hosts a lot of virtual domains, etc, and from the late '90s one important feature we had working was allowing IMAP clients to connect to both read and send from our mail server system. A key enabling feature was the pop-before-smtp option in Postfix.

The need for IMAP sends fell away with the financial crash of '08, but the need has come again, so, as administrator, I set about configuring the modern Postfix and Dovecot, of course on a modern Fedora Server (our long-chosen distribution) to do the job.

Configuring to have IMAP (IMAPS or POP3) reads was easy, but pop-before-smtp was neither rejected nor honored. Hmmm...

Configuring remote sends hasn't gone so well!

Troubles

As a guy with a long-grey-beard of experience, I did all the usual kinds of things looking for help, though I didn't do everything perfectly.

Along the way to this not-yet-solved problem, I figured out that THESE version(s) of Postfix and Dovecot don't work as advertised. In particular, we're running:

• Linux Fedora Server 5.7.16-200.fc32.x86_64
• postfix-3.5.4-2.fc32.x86_64
• dovecot-2.3.10.1-1.fc32.x86_64

With THIS set of versions, the settings for both Dovecot and Postfix didn't seem to honor the communication settings, shared by each, namely:

private/auth

Rather, things worked MUCH better, but still not fixed, with:

/var/spool/postfix/private/auth

When I say both, I mean the smtpd_sasl_path entry in Postfix's main.cf, and also Dovecot's /etc/dovecot/dovecot.d/10-master.conf file's entry for unix_listener, of course.

These entries point to a socket created by Dovecot, so Dovecot should be started first, though I haven't done any investigations into restart, or related issues. Simply, CONTRARY WITH OTHER DOCUMENTATION, THIS VERSION of Postfix WILL NOT receive inbound email if SASL auth is enabled and the smtpd_sasl_path doesn't already exist, as created by Dovecot.

I don't mean to overlook that several other Postfix parameters MUST be set for Postfix to receive emails under this scenario, such as smtpd_sasl_security_options and smtpd_sasl_tls_security_options. Without these, Postfix WILL NOT RECEIVE EMAILS if smtpd_sasl_auth_enable is set true.

To be completely clear, to cure this oversight, if you aren't able to receive email while trying to configure this, you simply MUST turn off Postfix's smtpd_sasl_auth_enable - that is, set it to false - or you will be unable to receive inbound emails, despite the available documentation's claims to the contrary. So, turn it off when you want to receive emails and back on again when you want to test.

However, even when you figure out how to get Dovecot to start enabling this service, as confirmed by the creation of /var/spool/postfix/private/auth, you can have smtpd_sasl_auth_enable set to true (along with other required sasl settings) and be able to receive emails, and still not be able to send via IMAP (imaps) clients.

As an aside I haven't taken the time to fully pursue, in my case, why or how the socket file created at /var/spool/postfix/private/auth was created as owned by root.root. After Postfix was up and receiving with sasl enabled, a chown postfix.postfix /var/spool/postfix/private/auth was required to fix that and I haven't taken the time to confirm this survives a reboot or even why it was wrong in the first place or if it fails if ownership is wrong! I'm just sharing my experience... ... It surely seems wrongly created to me.

YET, even in this instance, when Dovecot and Postfix agree on where and how to communicate via this socket file and email is received just fine, sends just do not work. That is, clients can connect and read their emails and do whatever else, but they cannot send, which all available documentation I've found so far leads one to believe the implementation of sasl done in this way is the key feature of the modern situation that permitted the deprecation and eventual removal of pop-before-smtp. What have I missed?

Before anyone asks, Postfix's /etc/postfix/master.cf's submission entry contains:

submission inet n       -       n       -       -       smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=may -o smtpd_sasl_auth_enable=yes

(Perhaps there is an error there, but it's not clear to me.)

When trying to send, the /var/log/maillog presently (with the aforementioned configuration fully working) and persistently includes the following error for these remote-sending clients:

 400 4.5.2 Error: bad UTF-8 syntax

And, more rarely, this one:

 250-SMTPUTF8

I have never found any useful information about this error.

Any and all help appreciated.

Doing my homework, this Server Fault Question speaks to an identical error message and it might have the same cause, but how I got there is likely different and may provide clues.

In my case the system in trouble is one of a small number of otherwise identical servers that do firewall / gateway services, and they were configured and working fine. Unfortunately our immortal power supply failed recently and was not yet replaced when we just had a nasty power hit. (Tip: NEVER let your bean-counters convince you you can run temporarily without power supply protection on your servers!)

All the systems came back except one of the firewall / gateway boxes. It rebooted fine but the firewall was not behaving as configured, so I went to investigate.

I didn't recall what the zone names were on the box so the first thing I noticed was that this command returned NOTHING:

# firewall-cmd --get-active-zones

Hmmm. That's odd? So, I grabbed the script hidden away in the root's home directory that configures the net for this system (to make it easy to clone), and it seems to run all the various firewall-cmd commands EXCEPT these:

# firewall-cmd --add-interface=enp2s0 --zone=public
# firewall-cmd --add-interface=enp3s0 --zone=internal

Instead, it spits out two nearly identical instances of this noise:

Error: COMMAND_FAILED: 'python-nftables' failed: internal:0:0-0: Error: No such file or directory


JSON blob:
{"nftables": [{"metainfo": {"json_schema_version": 1}}, {"add": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_IN_public", "index": 4, "expr": [{"match": {"left": {"meta": {"key": "l4proto"}}, "op": "==", "right": {"set": ["icmp", "icmpv6"]}}}, {"accept": null}]}}}, {"add": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_FWDI_public", "index": 4, "expr": [{"match": {"left": {"meta": {"key": "l4proto"}}, "op": "==", "right": {"set": ["icmp", "icmpv6"]}}}, {"accept": null}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "raw_PREROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "raw_PRE_public"}}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "mangle_PREROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "mangle_PRE_public"}}]}}}, {"insert": {"rule": {"family": "ip", "table": "firewalld", "chain": "nat_PREROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "nat_PRE_public"}}]}}}, {"insert": {"rule": {"family": "ip6", "table": "firewalld", "chain": "nat_PREROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "nat_PRE_public"}}]}}}, {"insert": {"rule": {"family": "ip", "table": "firewalld", "chain": "nat_POSTROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "oifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "nat_POST_public"}}]}}}, {"insert": {"rule": {"family": "ip6", "table": "firewalld", "chain": "nat_POSTROUTING_ZONES", "expr": [{"match": {"left": {"meta": {"key": "oifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "nat_POST_public"}}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_INPUT_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "filter_IN_public"}}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_FORWARD_IN_ZONES", "expr": [{"match": {"left": {"meta": {"key": "iifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "filter_FWDI_public"}}]}}}, {"insert": {"rule": {"family": "inet", "table": "firewalld", "chain": "filter_FORWARD_OUT_ZONES", "expr": [{"match": {"left": {"meta": {"key": "oifname"}}, "op": "==", "right": "enp2s0"}}, {"goto": {"target": "filter_FWDO_public"}}]}}}]}

I'm not particularly skilled with python, but it seems to have lost track of some configuration information. If it told me what file(s) were missing, I might be able to recover from one of its siblings, or maybe there's another way.

An additional clue might be that even though all the other configuration commands worked fine, and even though I could see the changes, and even though I used --runtime-to-permanent, following reboot the results of these commands were lost AND the system refused to honor its newly configured IP address (basically to take it out of service while it's being fixed) and persistently demanded that it was its old public IP. NOT OK! So, I merely unplugged the cable. Thankfully, the private interface did reconfigure properly so we can still get to it without having to be at the console.

Ideas?

I'm pondering removing the packages related and reinstalling / reconfiguring - these are:

firewalld-filesystem-0.8.3-1.fc32.noarch
python3-firewall-0.8.3-1.fc32.noarch
firewalld-0.8.3-1.fc32.noarch

But I don't have a good understanding yet if there are dependencies I haven't considered or whatnot. ... Does "refresh" of these packages hold a chance? I suppose that's my first thing to try after posting this question!

My beard is solid grey now, and I long recall using NFS for all these decades and here I cite the original RFC that gives us the basis for the NFS we have today RFC1094. Of course, three decades and some have passed since then, so here's the question:

In the interim has it become possible now, via a configuration option, to have links interpreted from the server side? This would surely clear up a number of my problems of client-side interpretation of links!

Or, am I all wet, and what I'm citing is obsolete and it's really, by default, resolving on the server side and I'm just chasing rabbits down rabbit-holes in my troubleshooting?

IF IT'S STILL OLD-SCHOOL AND INTERPRETED CLIENT SIDE, and if there is NOT an option that enables server-side interpretation, does using relative links instead of absolute ones possibly help?

Thanks.

Background

I had a new system that I'd spent a lot of time configuring the software on to perform all manner of services and then discovered the drive was potentially flaky. So I decided to replace the disk, keeping the contents for the new disk.

The system disk also had a problem booting into correct kernel that I couldn't seem to fix (I followed all the grub directions but it just woudn't boot the right kernel by default, only if you manually chose the right one). So, I figured the best way was to simply do a new installation of Fedora Server onto the new disk and that would fix the boot problem along the way.

What Happened

The new disk was a lot bigger, so I partitioned it a little differently during the installation process. I then removed the drive and put both the new and the old system disk into another server I had nearby. Out of an abundance of caution, I kept the fstab from the new system disk, knowing it had the partition UUIDs.

There are many ways to move things around and I decided I wanted a clean root partition on the new system disk. I figured dd might be able to do this but I'm used to using it where the partitions are the same size and was a little unsure, so instead I just reformatted the root partition ("/") with gparted. I then moved the files over using normal OS tools. I then cut and pasted the UUID stuff from the new installation and inserted it into the very-non-stock fstab from the server I was fixing.

That went fine.

I then attempted to boot the system. It posted, then got to the grub boot loader, it automatically selected the right kernel and away it went! ... Until it didn't!

It got to "show Plymouth Boot Screen" or something like that, paused, and then gave a lot of timeout warnings from something calling itself dracut. From here, I took a screen shot with my phone. It says:

Warning: Could not boot.
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-uuid/<a uuid> does not exist
Generating "/run/initramfs/rdsosreport.txt"

followed by a suggestion to use journalctl and perhaps to save the rdsosreport.txt for bug reporting.

ACK! What to do? I searched high and low for this the Warning [...] does not exist and dracut emergency shell stuff cited above. Nada!

I have a script that needs to send emails to notify about system events and status - a pretty common use-case, I'd think - and I chose to use mailx for this (why I no longer remember) on my Fedora Server system.

Everything was just fine and dandy until a recent upgrade whereupon I started getting an extra email for every one sent. The first line identifies the mail system host. The second line reads:

Enclosed is the mail delivery report that you requested.

Except that I didn't knowingly or willingly request the email delivery report! They just started showing up post-upgrade. (Either that, or my client-side spam filter - Thunderbird) was killing them for me, I suppose?! It's weird, sometimes doing a great job, then suddenly catching nothing at all?! -shrug- )

I suppose I can use an explicit directive in my mail reader's "filters" to get rid of these, but I'd rather they not be generated in the first place - the emails that are sent are what's valuable and I just don't need or want these "delivery report"s.

I started with mailx's man page. Nothing useful there, or, at least, I didn't recognize any setting for this type of thing. I STRONGLY suspect this is generated somehow by the interaction of mailx and Postfix, though that's only a hunch. I get exactly one mail status report per call to mailx, but none when I either send mail via alpine or Thunderbird from the same account through the same Postfix installation.

Here's the pattern the code uses:

/bin/mailx -n -s "subject" -s from=from_address to_address < content

The -n means don't read any local configuration. The -S indicates setting a "variable", in this case specifying a from address.

I took the Postfix queue ID and used grep to find it in /var/log/maillog:

Aug 11 12:14:32 fs1 postfix/pickup[233386]: C834918E658F: uid=nnnn from=<SystemUsername>
Aug 11 12:14:32 fs1 postfix/cleanup[237953]: C834918E658F: message-id=<5f32ee18.AXOWyPor64xZtCVH%From@EmailAddress>
Aug 11 12:14:32 fs1 postfix/qmgr[4780]: C834918E658F: from=<SystemUsername@PostfixsPrimaryFQDN>, size=1511, nrcpt=1 (queue active)
Aug 11 12:14:32 fs1 postfix/local[237956]: C834918E658F: to=<Recipient@EamilAddress>, relay=local, delay=0.14, delays=0.05/0/0/0.08, dsn=2.0.0, status=sent (delivered to mailbox)
Aug 11 12:14:32 fs1 postfix/bounce[238851]: C834918E658F: sender delivery status notification: E2BC718E6D06
Aug 11 12:14:32 fs1 postfix/qmgr[4780]: C834918E658F: removed

I noticed that sometimes there was an expansion of the delivery address and other times not. So, that would, I'd think, rule out the known quirk where Postfix sends status emails when asked to do expansion validation, "does this exist" checks.

All the deliveries are local in this instance, but they could be remote - I just don't have a live occurrence of that right now - this is an in-production server.

I've looked hard on where to find them, but most all my web searches point me at materials discussing bounce status messages. Nope, wrong thing!

The system:

Fedora Server 32 (booted into 31 presently)
mailx 12.5 7/5/10
postfix-3.5.4-2.fc32.x86_64

As discussed here, I've been working to load a great many smaller disks' data to a larger storage repository. The system in question is Fedora Core Server 31 - out just a week ago or less. Of course, I added a few tools to the base Server download including Gnome, gnome-disks, and gparted, because these are all handy.

Everything worked as expected regarding working with the disks via a combination of command line and graphical tools, and I managed to process maybe a dozen disks, salvaging what data they could contribute to our effort, up until a point which is the basis if this question.

Prior to this moment, I was able to get SMART data from all disks via gnome-disks, including a few IDE drives (as I recall) and I managed to salvage a LOT of data from ancient drives.

But at some point gnome-disks quit providing an option to select / fetch the SMART data from the drives (anything but the system disk) , simply greying-out the option to fetch SMART data, and providing an orange-square base for its graphical display (which was normally a different, non-orange color). As everything else was functional, I ignored the loss of data about the drive's hours of service, whether the assessment was "OK" and so on...

Unfortunately, it got worse. At some point I did a reboot, thinking it would help, but no, things got worse. Now gnome-disks only provides an empty screen with the only content being "Select a device". ... It presents exactly zero choices, not even the obviously available system disk.

Puzzling, though, is that gparted is capable of displaying all the disks, and by using it, I've been able to see what partitions exist and have easily mounted them, and done some other work. So, why can gparted see these disks and gnome-disks can not? And, What do I do about it? Until I get a good answer, I'm back to the command-line-only environment (not that I'm uncomfortable with it - I've only been doing this work since 1977, long before graphical tools became available), or, I back-pedal and install a younger version of Fedora (or some other release entirely, perhaps - your comments on that are welcome).

Any help / insight appreciated.

UPDATE:

First, an additional reboot cured the "Select a device" problem reported above.

Next up, as indicated above, I went to command-line tools and regarding a drive that gnome-disks sees but won't give SMART data for and which shows the disk as an orange square, I used smartctl -i and proved that the drive is fine and, vitally, SMART support is both enabled and available, though it did say the drive was not in the smartctl database. (That didn't seem to stop gnome-disks BEFORE the glitch - this same drive displayed properly previously.)

Here's an excerpt of the smartctl dialogue:

# smartctl -i /dev/sdb
smartctl 7.0 2019-03-31 r4903 [x86_64-linux-5.3.7-301.fc31.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     ST14000NM0018-2H4101
Serial Number:    xxxxxx
LU WWN Device Id: xxxxxx
Firmware Version: SN02
User Capacity:    14,000,519,643,136 bytes [14.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Nov  3 15:51:43 2019 PST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

...I'm guessing it's time to report a bug? Hmmm...

I installed Fedora on this one machine which is EXCLUSIVELY a gateway / firewall system.

Following installation, I ran 'yum upgrade', and so it should be up to the very latest Fedora 21 - I'm a little behind on purpose (not Fedora 22) specifically so that any problems are hopefully fixed (and now realize MAYBE I should have gone for Fedora 20?!)...

As soon as I got it up, I configured the two NICs in the box with their respective IP addresses, rebooted, confirmed they were fine, and began the "firewall" setup. First, I ran:

# firewall-cmd --list-all-zones

I confirmed that the names of the interfaces that firewalld is using are consistent with the other tools (unlike past versions of Fedora, such as 19 - see FC19 FirewallD debugging help requested: ports not forwarding )

To put the interfaces into the correct zones, I then ran:

firewall-cmd --permanent --zone=external --change-interface=enp2s0
firewall-cmd --permanent --zone=internal --change-interface=enp5s4

..and went on to try and set up port forwarding, etc. There are a couple of steps, such as opening up the port, then forwarding it. However NONE of that worked. After some digging, I found this article, dated only a few days ago, so I figured it's very current - http://www.certdepot.net/rhel7-get-started-firewalld/ - and followed its advice to edit /etc/sysctl.conf and add a line reading net.ipv4.ip_forward=1 and activate it with # sysctl -p, however, unhappily, things actually went "backwards"...

Previously, attempted connections to a forwarded port were hanging but now they were returning:

ssh: connect to host 167.101.97.2 port 6543: No route to host

So, I attempted to restore things to normal by UN-DOING the port-forwards and the edits to sysctl.conf, but things did NOT go back to "original!"

Incredulously, I rebooted, with everything set up as back to the default, just installed condition as I could - except for those zone changes; what harm could THEY do?! But when the system came back up, THE INTERFACES HAD GONE BACK TO THE DEFAULT ZONE!

I then tried it all over again. Nope! The interfaces STAY IN THE "FedoraServer" zone following reboot NO MATTER WHAT I DO. I've tried the --permanent in several different positions in the command line. Every time the response is "success", and yet, every time the result is it doesn't survive a reboot, even if that's the ONLY thing done on the system between reboots.

...It's enough to shake a person's loyalty to their (otherwise) favorite Linux distribution! ...Don't let me tell you what I really think!

OK, SURELY this was tested; how's this done? (YES, I'd like to know about the port forwarding, but here I'm ONLY asking about the zone changes for interfaces surviving reboot.)

ADDITIONAL DATA:

So, I got the idea that MAYBE it was NetworkManager getting in the way, as it has often done in the past. However, none of my efforts there were fruitful. The first effort was to simply set NM_CONTROLLED="no" in the interfaces' files in /etc/sysconfig/network-scripts but that left the system with NO interfaces!

I then had to go back into my past to remember it was "network.service" that was present before and thankfully it was already installed. So, I ran:

systemctl disable NetworkManager.service
systemctl enable network.service

And the interfaces were then available. However, after reboot - AND ensuring the requisite firewall-cmd commands were executed (see above) - unfortunately, it again didn't work.

I then tried changing the NM_CONTROLLED values to "no", but that didn't work either.

I was unable to find any help anywhere on installing Clamav on a modern Fedora system. All the advice out there is old and doesn't apply - so far as I found anyway.

And, it's not enough straight-forward that I know what to do! The most important missing link appears to be what I tell to Postfix on how to call ClamAV. However, it's also completely unclear where configuration options are to be defined.

I've installed these versions:

clamav-0.98.6-1.fc21.x86_64 
clamav-filesystem-0.98.6-1.fc21.noarch 
clamav-data-0.98.6-1.fc21.noarch 
clamav-lib-0.98.6-1.fc21.x86_64

And again, this is Fedora Core 21. The installed Postfix is:

postfix-2.11.3-1.fc21.x86_64

I can't seem to find a file called clamav-milter.conf, though there's a man page for it (try 'man clamav-milter.conf') Somewhere I found a reference that intimated that file belongs in /etc.

I imagine that there needs to be an entry made in Postfix's main.cf to create or add an entry called smtpd_milters to include whatever link is needed to tell Postfix how to call clamav. PRESENTLY I have an entry for openDKIM:

# This is for openDKIM - missing are clamav and spamassassin:
smtpd_milters = inet:localhost:8891

CLEARLY there should be installation directions somewhere, but NONE of what I've found pertains to these versions. Please either tell me how this should be done or point me to where I can find a competent write-up that DOES apply!

In upgrading from Fedora Core 16 to Fedora Core 21, one of the challenges has been getting postfix working with postgrey. I still don't have it working after many long hours focused on it.

In the old strategy, the official directions direct you to author your own script to put into /etc/init.d. And, indeed, way back on FC16, I did that! But today, we have systemctl. You can install postgrey with yum, the repositories know about it. It installs fine. You then enable with systemctl enable postgrey.service, and that goes well too.

So far so good. Just a few things left to do...

Next, move over your whitelisting files - seem to be of the same format.

In the old scheme, you'd have a line like this in your postfix main.cf file:

...
smtpd_recipient_restrictions = permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_pipelining,
                               reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               reject_unauth_destination,
                               check_policy_service inet:127.0.0.1:10023,
                               permit_mynetworks
...

In my /etc/init.d, I had written a script of which the following excerpt shows the interesting parts, and it worked well:

...
exec="/usr/sbin/postgrey"
prog="postgrey"
options="--unix=/var/spool/postfix/postgrey/socket --inet=10023"

[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog

lockfile=/var/lock/subsys/$prog

start() {
    [ -x $exec ] || exit 5
    echo -n $"Starting $prog: "
    daemon $exec -d $options
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}
...

Notice how the port is specified in --inet= and it matches what's in main.cf.

But, when I try and use this, the postfix server complains and it won't receive email. It explicitly states it can't connect to postgrey:

...
Apr 12 13:27:50 ms1 postfix/smtpd[14273]: warning: connect to 127.0.0.1:10023: Connection refused
Apr 12 13:27:50 ms1 postfix/smtpd[14273]: warning: problem talking to server 127.0.0.1:10023: Connection refused
...

I've looked and looked and can't find any configuration information for the new scheme. Asking if postgrey is up and happy gets this:

# systemctl status postgrey.service -l
● postgrey.service - Postfix Greylisting Service
   Loaded: loaded (/usr/lib/systemd/system/postgrey.service; enabled)
   Active: active (running) since Sun 2015-04-12 12:13:19 PDT; 1h 19min ago
     Docs: man:postgrey(8)
  Process: 13280 ExecStart=/usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %%s seconds --daemonize $POSTGREY_OPTS (code=exited, status=0/SUCCESS)
  Process: 13277 ExecStartPre=/bin/rm -f /var/run/postgrey.pid (code=exited, status=0/SUCCESS)
 Main PID: 13281 (/usr/sbin/postg)
   CGroup: /system.slice/postgrey.service
           └─13281 /usr/sbin/postgrey --unix=/var/spool/postfix/postgrey/socket --pidfile=/var/run/postgrey.pid --group=postgrey --user=postgrey --greylist-text=Greylisted for %s seconds --daemonize --delay=6

Apr 12 12:13:19 ms1 postgrey[13281]: Process Backgrounded
Apr 12 12:13:19 ms1 postgrey[13281]: 2015/04/12-12:13:19 postgrey (type Net::Server::Multiplex) starting! pid(13281)
Apr 12 12:13:19 ms1 postgrey[13281]: Binding to UNIX socket file "/var/spool/postfix/postgrey/socket"
Apr 12 12:13:19 ms1 postgrey[13281]: Setting gid to "479 479"
Apr 12 12:13:19 ms1 postgrey[13281]: Setting uid to "984"

Oddly, it doesn't clearly denote the socket ID - maybe it doesn't have to? But I checked with netstat anyway:

# netstat -l | grep postgrey
unix  2      [ ACC ]     STREAM     LISTENING     126293   /var/spool/postfix/postgrey/socket

...I'm not an expert with netstat, but I think this means that the program /postfix/postgrey/socket is listening on port 126293.

So, am I supposed to alter my line in main.cf to match this port number? If so, that doesn't work - or, hasn't so far! And, I can't seem to find the place to put an alternate port / socket configuration, so it looks like you're stuck with whatever they gave us.

Any help / advice appreciated. ... I was thinking the only course of action next is to figure out how the systemctl toolset works, even though I don't want to take the time now - it's a Sunday!

Following upgrade of Fedora Core 16 to Fedora Core 21, the new Dovecot installation isn't authenticating correctly and it's not at all clear why.

We have 50+ email accounts served by this server, so I was hoping to keep the previous schemes working for people.

We've been using CRAM-MD5 quite successfully for many years. I moved over the configuration, updated as necessary for the new version (2.2.15-3), and tried to connect. The log says:

Requested CRAM-MD5 scheme, but we have only CRYPT

Yet, when I follow the guidance from the Dovecot web site on testing (which can be found here http://wiki2.dovecot.org/TestInstallation ), the test command shows that CRAM-MD5 is indeed available:

# telnet localhost 143
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
 IDLE STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=PLAIN AUTH=LOGIN]
 Dovecot ready.

As can be seen, CRAM-MD5 is the first supported authorization type listed.

Further, the dovecot parameter testing program shows no issues, either:

# dovecot -n
# 2.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 3.17.4-301.fc21.x86_64 x86_64 Fedora release 21 (Twenty One)
auth_debug = yes
auth_debug_passwords = yes
auth_mechanisms = cram-md5 digest-md5 plain login
auth_verbose = yes
listen = *
login_trusted_networks = 192.168.1.4 192.168.1.5 192.168.1.6
192.168.1.12 192.168.1.14 192.168.1.10 127.0.0.1
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix =
}
passdb {
  driver = passwd
}
quota_full_tempfail = yes
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    user = postfix
  }
}
ssl = required
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
userdb {
  driver = passwd
}
verbose_proctitle = yes

I've checked the permissions on the cram-md5 file are the same as on the old system, etc.

Any and all help greatly appreciated.

I have a C program that needs access to a protected directory full of stuff.strong text The idea is that only the program or the administrator have access.

In the past on Linux platforms, I've used the file-system SETUID and SETGID bits rather successfully. The program runs just fine as whatever the UID and GID the file system says is the owner of the executable no matter who runs it.

Or, rather, it used to run successfully.

I don't know exactly when this change occurred because I only tend to update the OS when there's a hardware failure, so I get both updates at once... So, given lots of versions are skipped, I, only that as of right now, the development system that's on Fedora Core 17 is no longer honoring these bits. As FC 19 is the current release, I imagine things are only worse with the latest release, not better.

Here's the 'ls -l' output:

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

In investigating a solution, I found the man page for chmod says this:

Additional restrictions may cause the set-user-ID and set-group-ID bits of MODE or RFILE to be ignored. This behavior depends on the policy and functionality of the underlying chmod system call. When in doubt, check the underlying system behavior.

OK, but I have NO IDEA how to check that policy and functionality as suggested! They offered no help but to use the info command - but I found nothing helpful there, only data about default user and group ownership for new file creation.

SELINUX is turned off.

Questions:

1. What is the "correct" way to do this kind of thing in the modern era?

2. How do I check the policies - and alter them?

Thanks for any input.

MORE DATA:

The C program simply has this line that's branching to output an error - an excerpt:

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");

So, I installed Fedora Core 19 for the first time as a replacement for an older system whose disk had finally died. The system serves as a web server and gateway / firewall, protecting internal systems. Because it has a lot of network configuration, I got an introduction to - and found I really like - the new firewall daemon, firewalld.

I thought everything was going well (that's always when trouble strikes) when suddenly I spotted the internal mail server's maillog file going crazy - it was only luck I happened to still be watching it some 6 hours after getting things working.

Investigation showed the issue was that my internal mail system (protected behind the firewall) somehow thought all the outbound mail was coming from the gateway system, it was therefore an "internal" system and spammers found it to be an open relay. I noticed also that somehow or other that BOTH the internal and external zones were marked "masquerade" and that in fact the perceived IP addresses in the maillog file were the IP of the gateway. Logging in through a forwarded ssh port also confirmed that the wrong IP was being used on the internal side.

NO PROBLEM!" I thought errantly. YES, turning off masquerading on the internal zone did fix the wrong IP being handed to the internal systems when coming through the gateway. However, it did NOT fix the problem because, inexplicably (so far!) it appears as though port 25 is no longer being forwarded!

OTHER ports are being forwarded, at least the easily tested ssh port I spoke of is. SO, I thought, I'll just turn on that fancy logging feature! Here's the command:

firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" forward-port port="25" protocol="tcp" to-port="25" to-addr="192.168.1.1" log prefix="smtp-to-inside" level="info"'

I tried it with the permanent option, and not, etc. NOTHING shows up in /var/log/messages - or any other logfile I could think of looking in. It's as if the kernel is just ignoring that port. I thought maybe the internal mail system might possibly block the foreign traffic with its firewall, BUT the gateway SHOULD be logging the connection attempts, but I get nothing.

Any and all help appreciated.

For someone with so much Java experience, boy do I feel clueless - thanks in advance for your help in my grocking the present (Feb, 2010) JSP environment.

Here's what I am hoping to learn:

• Do I understand correctly that most people use Apache to "front-end" their Tomcat servers, such that Apache "talks" directly to web clients and "proxies" Tomcat servers?
• Do I understand correctly that Apache isn't capable of serving JSP directly but requires a server (like Tomcat)?
• Is there an RPM package for Fedora Core so I don't have to build one myself? Or, does Fedora Core's package installer do a good job on this one from source code? (Some do, some don't!)

While I'm here asking questions; Does Tomcat come with a working example that one can start hacking on as a way to get started quickly? If not, got a good suggestion?

Thanks folks, RT