Tuesday, July 31, 2012

How to Install and Configure Munin 2.0 with Nginx and FastCGI on CentOS 6

Munin 2.0 introduced dynamic CGI graph and HTML generation, allowing monitoring dashboards to scale efficiently without requiring static graph regeneration during every 5-minute cron cycle. Here is how to compile Munin 2.0 from source and integrate it with Nginx using spawn-fcgi on CentOS 6.

Stack: Munin 2.0.x • Nginx • FastCGI (spawn-fcgi) • CentOS 6 / RHEL 6

1. Installing Build Dependencies

Install Perl module prerequisites and development tools:

yum groupinstall 'Development Tools' -y
yum install perl-CGI perl-FCGI perl-File-Copy-Recursive perl-Module-Build perl-Cache-Cache git spawn-fcgi -y
groupadd munin
useradd munin -g munin -s /sbin/nologin -d /var/www/html/munin

2. Compiling Munin 2.0 from Source

cd /usr/src
git clone git://github.com/munin-monitoring/munin.git
cd munin
git checkout tags/2.0.0
make
make install

3. Spawning FastCGI Processes for Graph and HTML Generation

Munin 2.0 relies on two FastCGI workers: one for HTML page rendering and one for real-time RRD graph generation.

spawn-fcgi -s /var/run/munin/fcgi-graph.sock -u munin -g munin -- /var/www/html/munin/cgi/munin-cgi-graph
spawn-fcgi -s /var/run/munin/fcgi-html.sock -u munin -g munin -- /var/www/html/munin/cgi/munin-cgi-html

4. Nginx Server Configuration

Configure Nginx to proxy requests to the Munin FastCGI sockets:

location ^~ /cgi-bin/munin-cgi-graph/ {
    access_log off;
    fastcgi_split_path_info ^(/cgi-bin/munin-cgi-graph)(.*);
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass unix:/var/run/munin/fcgi-graph.sock;
    include fastcgi_params;
}

location /munin/static/ {
    alias /etc/munin/static/;
}

location /munin/ {
    fastcgi_split_path_info ^(/munin)(.*);
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass unix:/var/run/munin/fcgi-html.sock;
    include fastcgi_params;
}

5. Testing

Execute the Munin cron job under the munin system user to build the initial state:

sudo -u munin munin-cron

Sunday, July 8, 2012

Setting Up an IKEv2 VPN with StrongSwan Between a NATed Linux Client and Server

Configuring a secure, roadwarrior-style IKEv2 IPsec VPN using StrongSwan allows a client behind a residential NAT router (such as a standard home DSL/Cable modem) to establish an encrypted tunnel to a remote dedicated server.

Topology: Client: Ubuntu (behind NAT) • Server: CentOS with StrongSwan 4.6.x (Public IP) • Protocol: IKEv2 with X.509 certificates

1. Server Configuration (/etc/ipsec.conf)

Define the IKEv2 connection on the server. The server listens on its public IP, provisions virtual IPs to clients from 10.10.3.0/24, and routes default internet traffic:

conn win7
    left=SERVER.IP.ADD.RESS
    leftcert=server.cert
    leftid=@server.domain.com
    leftsubnet=0.0.0.0/0
    right=%any
    rightsourceip=10.10.3.0/24
    keyexchange=ikev2
    auto=add
    leftfirewall=yes

2. Client Configuration (/etc/ipsec.conf)

On the client machine behind NAT, set left=%defaultroute and request an IP dynamically from the server via leftsourceip=%config:

conn ike
    left=%defaultroute
    leftsourceip=%config
    leftcert=client.cert
    leftid=@client.domain.com
    leftfirewall=yes
    right=SERVER.IP.ADD.RESS
    rightsubnet=0.0.0.0/0
    rightid=@server.domain.com
    auto=add

3. Initiating the Connection

Start the IPsec tunnel from the client:

ipsec up ike

Check the status to verify security associations (SAs):

ipsec statusall

Tuesday, July 3, 2012

How to Fix Postfix SASL Authentication Failure and Chroot Errors with saslauthd

When configuring Cyrus SASL (saslauthd) to authenticate SMTP users in Postfix on CentOS / RHEL with Virtualmin, you may encounter persistent user/password authentication failures even when credentials are valid.

Environment: CentOS 6.x / RHEL • Virtualmin • Postfix • Cyrus SASL (saslauthd)

1. Identifying the Symptom: /var/log/maillog

Checking /var/log/maillog often reveals that Postfix cannot communicate with the SASL authentication daemon:

warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory

2. The Chroot Trap and Secondary SMTP Failures

A common workaround suggested in forums is moving or binding the saslauthd socket into the Postfix spool directory (e.g. /var/spool/postfix/var/run/saslauthd). While that may resolve socket visibility, running Postfix processes inside a chroot jail introduces a severe secondary failure: outbound emails will fail to send entirely.

You will see delivery attempts stall in the active queue with errors like:

postfix/qmgr: from=<root@domain.com>, size=421, nrcpt=1 (queue active)
postfix/smtp: fatal: unknown service: smtp/tcp
postfix/qmgr: warning: private/smtp socket: malformed response
postfix/qmgr: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
postfix/master: warning: process /usr/libexec/postfix/smtp pid 29443 exit status 1
postfix/master: warning: /usr/libexec/postfix/smtp: bad command startup -- throttling
postfix/error: to=<user@example.com>, relay=none, delay=1.1, delays=0.1/1/0/0.03, dsn=4.3.0, status=deferred (unknown mail transport error)

Root Cause: When the Postfix smtp client daemon runs chrooted, it cannot access /etc/services to resolve the network port name smtp/tcp, causing the transport to abort and defer all outgoing mail.

3. The Permanent Solution: Disable Chroot for SMTP

To resolve both the SASL socket communication and the transport errors cleanly, configure the Postfix smtp process to run unchrooted.

Step 1: Edit master.cf

Open /etc/postfix/master.cf in your text editor:

nano /etc/postfix/master.cf

Locate the smtp service definition:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      unix  -       -       -       -       -       smtp

The 5th column controls chroot. A hyphen (-) defaults to enabled (yes). Change the 5th column from - (or y) to n:

smtp      unix  -       -       n       -       -       smtp

Step 2: Restart Services

Restart both saslauthd and postfix so the configuration changes take effect:

service saslauthd restart
service postfix restart

4. Verification

Once services are restarted, monitor the mail log while sending a test message or authenticating a mail client:

tail -f /var/log/maillog

SASL authentication will succeed immediately without socket connection errors, and the mail queue will flush smoothly without transport or chroot exceptions.

How Google Antigravity Solved the Mysterious NVIDIA Sleep Reboot on My Dell Inspiron 7567 (Ubuntu Linux)

If you run modern Ubuntu or Linux on a Dell Inspiron 15 Gaming (7567) or a similar 7th-gen Intel laptop paired with an NVIDIA GeForce GTX ...