Flimzy's questions

I'm using Debian 7.8 (wheezy), and lighttpd 1.4.31 with nagios 3.4.1.

when I start lighttpd normally (as root), everything works as expected:

/etc/init.d/lighttpd start

However, when nagios starts lighttpd, everything issues a 404 error, and nothing is logged to /var/log/lighttpd/access.log or /var/log/lighttpd/error.log. I can mimic the same behavior manually by issuing the following command as root:

su - nagios -s /usr/bin/sudo /etc/init.d/lighttpd start

The nagios daemon has sudo access, as defined in /etc/sudoers.d/nagios:

nagios ALL=(root) NOPASSWD: /etc/init.d/lighttpd *

What am I missing? What's the difference between starting lighttpd directly as root, and doing it as the nagios user via sudo?

We are querying a number (dozens) of LDAP servers (mostly Active Directory, but not exclusively) to determine which mailboxes are active, for the purpose of a mail gateway/forwarding application.

We have come across some instances where userAccountControl has bit 2 set to true (aka ACCOUNTDISABLE), but where the mailbox was still active.

I suppose this would correspond to a Windows login account which was disabled, but for whom the mailbox is still active.

Does this ever really make sense? Or is this simply a broken configuration?

If it does make sense, is there any way via LDAP to reliably detect this configuration (i.e. that userAccountControl is disabled, but that the mailbox is not disabled)?

We are currently ignoring the userAccountControl disabled attribute, because it seems to sometimes (although a small minority of cases) correspond to an active mailbox. We would like to reliably detect this situation rather than leaving these hundreds of "disabled" mailboxes active.

I'm trying to understand all the relevant implications of the --max-obj-size value used when creating an s3ql file system. I have yet to find a complete description of the implications of this option, but have been able to piece together a few bits from the docs and discussion groups.

Mainly, I have found reasons to use larger --max-obj-size values, which leaves me wondering, why not use an arbitrarily large value (10mb? 100mb? 1gb?):

• Smaller values mean more "inodes" are used, and worse performance from the sqlite database (as the same number of files requires more inode entries)
• Smaller values can hurt throughput (especially for sequential reads).

From the version 1.8 changelog:

As a matter of fact, a small S3QL block size does not have any advantage over a large block size when storing lots of small files. A small block size, however, seriously degrades performance when storing larger files. This is because S3QL is effectively using a dynamic block size, and the --blocksize value merperformanceely specifies an upper limit.

So far the only advantages I have found or imagined for smaller block sizes are:

• Less bandwidth used to re-write a portion of a file
• Possibly better deduplication

The --min-obj-size option does not affect deduplication. Deduplication happens before blocks are grouped.

The --max-obj-size affects deduplication, since it implicitly determines the maximum size of a block.

Found here:

Can anyone offer a summary of the trade-offs one makes when selecting a larger or smaller --max-obj-size when creating a s3ql file system?

I have rsyslog 4.6.4 configured to write mail logs to a PostgreSQL database. It all works fine, until the log message contains a backslash, as in this example:

Jun 12 11:37:46 dc5 postfix/smtp[26475]: Vk0nYDKdH3sI: to=<[email protected]>, relay=----.---[---.---.---.---]:25, delay=1.5, delays=0.77/0.07/0.3/0.35, dsn=4.3.0, status=deferred (host ----.---[---.---.---.---] said: 451 4.3.0 Error writing to file d:\pmta\spool\B\00000414, status = ERROR_DISK_FULL in "DATA" (in reply to end of DATA command))

The above is the log entry, as written to /var/log/mail.log. It is correct. The trouble is that the backslash characters in the file name are interpreted as escapes when sent to the following SQL recipe:

$template dcdb, "SELECT rsyslog_insert(('%timereported:::date-rfc3339%'::TIMESTAMPTZ)::TIMESTAMP,'%msg:::escape-cc%'::TEXT,'%syslogtag%'::VARCHAR)",STDSQL
:syslogtag, startswith, "postfix" :ompgsql:/var/run/postgresql,dc,root,;dcdb

As a result, the rsyslog_insert() stored procedure gets the following value for as msg:

Vk0nYDKdH3sI: to=<[email protected]>, relay=----.---[---.---.---.---]:25, delay=1.5, delays=0.77/0.07/0.3/0.35, dsn=4.3.0, status=deferred (host ----.---[199.85.216.241] said: 451 4.3.0 Error writing to file d:pmtaspoolB

The \p, \s, \B and \0 in the file name are interpreted by PostgreSQL as literal p, s, and B followed by a NULL character, thus early-terminating the string. This behavior can be easiily confirmed with:

dc=# SELECT 'd:\pmta\spool\B\00000414';
   ?column?   
--------------
 d:pmtaspoolB
(1 row)

dc=# 

Is there a way to correct this problem? Is there a way I'm not finding in the rsyslog docs to turn \ into \\?

Is there any way to control which hosts are permitted to connect to the cleanup daemon over TCP?

Our 'master.cf' contains:

2526      inet  n       -       -       -       0       cleanup

This is necessary because we have a cluster of SMTP servers running custom code, and they can all inject mail to the centralized postfix server via the cleanup daemon.

However, we want to allow only our authorized servers to connect to the cleanup daemon. The current configuration allows any host to connect to port 2526.

Clearly we can use iptables to restrict access, but is there a way to do this within postfix itself?

We are using postfix 2.7 and custom SMTPD (based on qpsmtpd) in highly customized configuration for spam filtering. We have a new requirement to filter postfix-generated bounces through our custom qpsmtpd process (not so much for content filtering, but to process these bounces accordingly).

Our current configuration looks (in part) like this:

main.cf (only customizations shown):

2526      inet  n       -       -       -       0       cleanup
pickup    fifo  n       -       -       60      1       pickup
  -o content_filter=smtp:127.0.0.2

Our smtpd injects messages to postfix on port 2526, by speaking directly to the cleanup daemon. And the custom pickup command instructs postfix to hand off all locally-generated mail (from cron, nagios, or other custom scripts) to our custom smtpd.

The problem is that this configuration does not affect postfix generated bounce messages, since they do not go through the pickup daemon.

I have tried adding the same content_filter option to the bounce daemon commands, but it does not seem to have any effect:

bounce    unix  -       -       -       -       0       bounce
-o content_filter=smtp:127.0.0.2
defer     unix  -       -       -       -       0       bounce
-o content_filter=smtp:127.0.0.2
trace     unix  -       -       -       -       0       bounce
-o content_filter=smtp:127.0.0.2

For reference, here is my main.cf file, as well:

biff = no
# TLS parameters
smtpd_tls_loglevel = 0
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtp_tls_security_level = may

mydestination = $myhostname
alias_maps = proxy:pgsql:/etc/postfix/dc-aliases.cf
transport_maps = proxy:pgsql:/etc/postfix/dc-transport.cf

# This is enforced on incoming mail by QPSMTPD, so this is simply
# the upper possible bound (also enforced in defaults.pl)
message_size_limit = 262144000
mailbox_size_limit = 0

# We do our own message expiration, but if we set this to 0, then postfix
# will try each mail delivery only once, so instead we set it to 100 days
# (which is the max postfix seems to support)
maximal_queue_lifetime = 100d

hash_queue_depth = 1
hash_queue_names = deferred, defer, hold

I also tried adding the internal_mail_filter_classes option to main.cf, but also tono affect:

internal_mail_filter_classes = bounce,notify

I am open to any suggestions, including handling our current content-filtering-loop in a different way.

If it's not clear what I'm asking, please let me know, and I can try to clarify.