Fedora Cinnamon Dual Monitor Display with Nvidia xorg.conf

I've recently changed my display from standard 60Hz monitors to 1920x1080 144Hz.

Unfortunately on my Fedora 30 running Cinnamon they're always set to 60Hz frequency.

To get 144Hz mode(or any other custom xorg.conf) you need to:
1) disable Cinnamon's xrandr daemon:
mv /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop /root
2) generate custom xorg.conf config using Nvidia X Server Settings GUI
For me I had to manually set resolution to 1920x1080 and refresh rate to 144Hz for both screens.
Save it as /etc/X11/xorg.conf
Note that by default Fedora does not have that file
3) Reboot and voilà

rsyslogd dying during heavy load

There was a case where rsyslogd (rsyslog5-5.8.12-7) was terminating when it got too many incoming logs to process and the central syslog server was not responding in timely manner.

A few extra config settings to the existing queues have helped to withstand the load:
$ActionQueueFileName logfile
$ActionQueueSize 100000
$ActionQueueSaveOnShutdown on
$ActionQueueResumeInterval 10
$ActionQueueDiscardMark 97500
$ActionQueueHighWaterMark 80000
$ActionQueueCheckpointInterval 100
$ActionQueueMaxDiskSpace 2g
$ActionQueueTimeoutEnqueue 0
$ActionQueueDiscardSeverity 0
$ActionQueueType LinkedList
$ActionQueueResumeRetryCount -1

How to fix rpmdb/yum issues

During my last yum update I ran out of memory and update has been aborted leaving rpmdb in inconsistent state.

When I tried to run it again I've got following error message:
Found 6 pre-existing rpmdb problem(s), 'yum check'
cronie-1.4.4-16.el6_8.2.x86_64 is a duplicate with cronie-1.4.4-15.el6_7.1.x86_64
cronie-anacron-1.4.4-16.el6_8.2.x86_64 is a duplicate with cronie-anacron-1.4.4-15.el6_7.1.x86_64
[..]

Quick fix:
package-cleanup --cleandupes

or:
package-cleanup --dupes
yum-complete-transaction


If you're lucky it should remove old package versions.

package-cleanup can also be executed with --problems flag.

Another cool feature of package-cleanup command is the ability to remove old kernel versions automagically:
package-cleanup --oldkernels

Mod_security issues with Roundcube, opencloud and other software

In case you find roundcube, opencloud or any other software working under apache/mod_security server having issues or strange behaviour check /var/log/httpd/modsec_audit.log for errors.

In my case I was not able to send/forward emails with national ("non-english") characters in the message content.

Some of the mod_security rules are outdated and they can produce false-positives.

Sample issue:
Message: Access denied with code 403 (phase 2). Pattern match "\\W{4,}" at ARGS:_message. [file "/etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_40_generic_attacks.conf"] [line "37"] [id "960024"] [rev "2"] [msg "Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters"] [data "Matched Data: ):\x0d\x0a>  found within ARGS:_message:...

If you believe that rule is not needed for your application you need to edit httpd.conf and add following rule to your (VirtualHost) config:
SecRuleRemoveById 960024

Restart apache, check if your app works now, if not - check for more issues in modsec_audit.log.

Cannot start teamviewer in Fedora 24

Default installation of Teamviewer on Fedora 24 will not start due to SELinux issues.

# systemctl -a | grep teamviewer
  teamviewerd.service  loaded   inactive dead  TeamViewer remote control daemon

# systemctl start teamviewerd.service
Job for teamviewerd.service failed because a fatal signal was delivered to the control process. See "systemctl status teamviewerd.service" and "journalctl -xe" for details.

To fix it you can use SELinux GUI tool:
sealert -b

Or CLI tool:
ausearch -c 'teamviewerd'

Or you can check system logs:
# journalctl -xe
aug 04 14:23:17 fedora setroubleshoot[3240]: SELinux is preventing teamviewerd from using the execmem access on a process. For complete SELinux messages. run sealert -l 7c667284-3d59-4c06-9535-2aed4b8015df
aug 04 14:23:17 fedora python3[3240]: SELinux is preventing teamviewerd from using the execmem access on a process.
                                     
                                      *****  Plugin catchall (100. confidence) suggests   **************************
                                     
                                      If you believe that teamviewerd should be allowed execmem access on processes labeled init_t by default.
                                      Then you should report this as a bug.
                                      You can generate a local policy module to allow this access.
                                      Do
                                      allow this access for now by executing:
                                      # ausearch -c 'teamviewerd' --raw | audit2allow -M my-teamviewerd
                                      # semodule -X 300 -i my-teamviewerd.pp

The solution(shown as a hint in sealert and journalctl), which is to run:
# ausearch -c 'teamviewerd' --raw | audit2allow -M my-teamviewerd
# semodule -X 300 -i my-teamviewerd.pp

 After that you should be able to start Teamviewer service:
 systemctl start teamviewerd.service
[root ~] # systemctl status teamviewerd.service
● teamviewerd.service - TeamViewer remote control daemon
   Loaded: loaded (/etc/systemd/system/teamviewerd.service; enabled; vendor preset: disabled)
   Active: active (running) since sun 2016-08-04 14:32:45 CEST; 1min 50s ago
  Process: 4228 ExecStart=/opt/teamviewer/tv_bin/teamviewerd -d (code=exited, status=0/SUCCESS)
 Main PID: 4230 (teamviewerd)
    Tasks: 19 (limit: 512)
   CGroup: /system.slice/teamviewerd.service
           └─4230 /opt/teamviewer/tv_bin/teamviewerd -d

aug 04 14:32:45 fedora systemd[1]: Starting TeamViewer remote control daemon...
aug 04 14:32:45 fedora systemd[1]: teamviewerd.service: PID file /var/run/teamviewerd.pid not readable (yet?) after start: No such file or directory
aug 04 14:32:45 fedora systemd[1]: Started TeamViewer remote control daemon.
 

fail2ban not working on EL6/Centos 6

I've noticed that fail2ban do not ban every host/IP which it should after a while.

First I checked if my regexps are correct:
fail2ban-regex /var/log/maillog /etc/fail2ban/filter.d/postfix-auth.conf --print-all-matched

Fortunately I've seen a lot of hits but most of them were not banned.
It appears that fail2ban is having issues monitoring log files.
Quick fix is to change the file monitoring backend from auto to polling.
Python inotify(pyinotify) or gamin may not work properly - you can read more about it here: https://github.com/fail2ban/fail2ban/issues/44

Edit your jail.local file, at the top add the following:
[DEFAULT]
backend = polling

Restart fail2ban and check its log file to see if it bans every IP it should.

using fail2ban to protect postfix/smtpd service

Recently I have found a lot of "lost connection after" entries in /var/log/maillog file:
lost connection after AUTH from unknown[IP.address]
lost connection after CONNECT 
lost connection after RCPT
lost connection after STARTTLS  
lost connection after UNKNOWN

It's possibly some kind of botnet trying to deliver spam using my mail server.
It won't work but it's still nice to get rid of such clients on the firewall level.

First you need to create a rule for fail2ban - create /etc/fail2ban/filter.d/postfix-auth.conf and put the following config:
# Fail2ban postfix-auth filter
[INCLUDES]
before = common.conf

[Definition]
_daemon = postfix/smtpd
failregex = ^%(__prefix_line)slost connection after .*\[<HOST>\]$
ignoreregex =

Next edit /etc/fail2ban/jail.conf and add postfix-auth service at the end of file:
[postfix-auth]
enabled  = true
port     = smtp,ssmtp
filter   = postfix-auth
action   = iptables[name=SMTP-auth, port=smtp, protocol=tcp]
logpath  = /var/log/maillog
maxretry = 2
bantime = 36000
findtime = 300

Finally restart fail2ban service and check /var/log/messages or iptables to see if your new rule works fine:
service fail2ban restart
grep Ban /var/log/messages
iptables -nvL

/var/log/maillog logpath is for Centos/Redhat.
For other distros make sure to point out proper mail.log file.