Samat Says (Posts about Debian)https://blog.samat.org/tag/debian.atom2018-06-29T09:25:27ZSamat K JainNikolaEnabling HTTP/2 on Apache 2.4 on Debian or Ubuntuhttps://blog.samat.org/2015/11/26/Enabling-HTTP2-on-Apache-2.4-on-Debian-Ubuntu/2015-11-26T00:00:00Z2015-11-26T00:00:00ZSamat K Jain<div><p><a class="reference external" href="https://httpd.apache.org/docs/2.4/mod/mod_http2.html">Apache 2.4.17 ships with mod_http2</a>.
Available in Debian 9 (stretch) and <span class="strike">Ubuntu 16.04 (Xenial Xerus)</span> (see comments) Ubuntu 16.10 (Yakkety Yak),
it brings HTTP/2 support to one of the Internet's popular Web servers.
Assuming you've already configured a SSL/TLS Website, this quick tutorial will show you how to quickly enable HTTP/2.</p>
<p>Based on <a class="reference external" href="https://icing.github.io/mod_h2/">mod_h2</a>, the module is still very experimental.
It should be enabled manually, on a site-by-site basis, via the <a class="reference external" href="https://httpd.apache.org/docs/2.4/mod/core.html#protocols">Protocols directive</a>.
The module's defaults otherwise don't need to be changed.</p>
<p>First, enable the module:</p>
<pre class="code sh"><a name="rest_code_40dd213b29044b90a0274126674c0091-1"></a>sudo a2enmod http2
</pre><p>In the <VirtualHost> stanzas for your Website served over TLS in your Apache configuration, add the Protocols directive:</p>
<pre class="code apache"><a name="rest_code_144f128ccf994f22abc932a08616bfab-1"></a><span class="nt"><VirtualHost</span> <span class="s">*:443</span><span class="nt">></span>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-2"></a> <span class="nb">ServerName</span> example.com
<a name="rest_code_144f128ccf994f22abc932a08616bfab-3"></a>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-4"></a> <span class="nb">Protocols</span> h2 http/1.1
<a name="rest_code_144f128ccf994f22abc932a08616bfab-5"></a>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-6"></a> <span class="c"># Other configuration stuff here…</span>
<a name="rest_code_144f128ccf994f22abc932a08616bfab-7"></a><span class="nt"></VirtualHost></span>
</pre><p>Restart Apache:</p>
<pre class="code sh"><a name="rest_code_c1307c7b66dc472d9ff614cfac9f5def-1"></a>sudo service apache2 restart
</pre><p>If you've curl 7.34.0 or later, you can test whether HTTP/2 is working by running:</p>
<pre class="code sh"><a name="rest_code_eceda1c831cd4a80b484e124d3e8850b-1"></a>curl -k -v --http2 https://example.com/
</pre><p>and look for mentions of "http2".</p>
<p>While you're fiddling with your Web server configuration, consider updating your SSL settings with <a class="reference external" href="https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.17">Mozilla's great SSL configuration generator</a>.</p></div>Increase file descriptors for Transmission on Linuxhttps://blog.samat.org/2011/04/05/Increase-file-descriptors-for-Transmission-on-Linux/2011-04-05T00:00:00Z2011-04-05T00:00:00ZSamat K Jain<div><p>Have you run out of file descriptors for <a href="http://www.transmissionbt.com/">Transmission</a>? The torrent will be stopped (for no apparent reason), and when you examine it, you'll see an error similar to:</p>
<pre><samp><span class="prompt">$</span> <kbd>transmission-remote -t 1 -i | grep -i 'open files'</kbd>
Unable to save resume file. Too many open files.
</samp></pre>
<p>Time to increase the number of file descriptors available. This article is tailored towards Debian and Ubuntu.</p>
<p>It's unlikely you'll need to raise your system's global limit. Check with:</p>
<pre><samp><span class="prompt">$</span> <kbd>cat /proc/sys/fs/file-max</kbd>
397460
</samp></pre>
<p>The OS needs a couple thousand file descriptors for itself. Make sure to make space for them with whatever numbers to choose below. In my case, I've more than enough.</p>
<p>If you still need to raise your system's limit, you can easily; to set it to a million (which will be remembered across reboots):</p>
<pre><samp><kbd>sudo sh -c "echo fs.file-max=$(dc -e '2 20 ^ p') > /etc/sysctl.d/file-descriptors-max.conf</kbd>
<kbd>sudo service procps restart</kbd>
</samp></pre>
<p>While you may not need to change your system's global limit, you probably will need to change the limit for your users. Check that limit with:</p>
<pre><samp><span class="prompt">$</span> <kbd>ulimit -Sn</kbd>
1024
<span class="prompt">$</span> <kbd>ulimit -Hn</kbd>
1024
</samp></pre>
<p>If you're working with hundreds of torrents (each with dozens to hundreds of files) with Transmission, this isn't enough. To let a user have a few thousand (in the below example, 16,384, with 128 more for the hard limit), create a new file /etc/security/limits.d/debian-transmission.conf:</p>
<pre><samp><kbd>sudo sh -c "echo debian-transmission soft nofile $(dc -e '2 14 ^ p')" > /etc/security/limits.d/debian-transmission.conf</kbd>
<kbd>sudo sh -c "echo debian-transmission hard nofile $(dc -e '2 14 ^ 2 7 ^ + p')" >> /etc/security/limits.d/debian-transmission.conf</kbd>
</samp></pre>
<p>Replace "debian-transmission" with the user that is running Transmission.</p>
<p>For the changes to go into effect, you need to logout completely (e.g. close multiplexed SSH connections, etc), and log back in again. Or to be sure, just reboot to make sure changes kick in. You'll see you have many more file descriptors available:</p>
<pre><samp><span class="prompt">$</span> <kbd>ulimit -Sn</kbd>
16384
<span class="prompt">$</span> <kbd>ulimit -Hn</kbd>
16512
</samp></pre>
<p>Now, we need to configure Transmission to use this many. In /etc/transmission-daemon/settings.json, find the open-file-limit option and set to a larger number (e.g. 16000 or so). When done, restart transmission-daemon:</p>
<pre><samp><kbd>sudo service transmission-daemon restart</kbd>
</samp></pre>
<p>If you're not running Transmission as a system user, edit the right settings.json and restart the daemon appropriately.</p>
<p>That's it. Have fun!</p></div>High-resolution text console with uvesafb and Debianhttps://blog.samat.org/2010/11/09/High-resolution-text-console-with-uvesafb-and-Debian/2010-11-09T00:00:00Z2010-11-09T00:00:00ZSamat K Jain<div><p>While you may rarely use the console on your server, it's nice to have a high-resolution display just to see that many more columns and rows. Linux's vesa module (via the vga= parameter) has been around for a while and made this possible, provided you kept up with what VGA mode number to use and don't mind the spotty hardware compatibility.</p>
<p>While <abbr title="Kernel Mode Setting">KMS</abbr> is the way to do this in the future, it doesn't help us with the drivers and hardware we have now. A new kernel module, <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt;h=eefdd91d298a9c9ea45e1ab9d84cdbf8ea1f1908;hb=HEAD">uvesafb</a>, mainlined in 2.6.24, is another, new option. In addition to specifying modes in a more user-friendly way (e.g. 1280x1024-32 for 32-bit color, with a 1280x1024 resolution), hardware compatibility is better—in particular, you can now get a high-resolution text console with NVIDIA display adapters.</p>
<p>In the following, I describe how to use uvesafb on Debian and derivative distributions (e.g. Ubuntu). The instructions assume kernel 2.6.27 or higher (Debian 6.0 (squeeze) and Ubuntu 8.10 (Intrepid Ibex), or later).</p>
<p><a href="https://blog.samat.org/2010/11/09/High-resolution-text-console-with-uvesafb-and-Debian/">Read more…</a> (2 min remaining to read)</p></div>Speeding up SpamAssassin rule processing on Debian and Ubuntuhttps://blog.samat.org/2008/10/02/speeding-up-spamassassin-rule-processing-on-debian-and-ubuntu/2008-10-02T00:00:00Z2008-10-02T00:00:00ZSamat K Jain<div><p><a href="http://spamassassin.apache.org/">SpamAssassin</a> is one of the most-used spam filtering systems in use today. Unfortunately, because there are so many different ways SpamAssassin can be used, SpamAssassin remains subject to many performance problems. Fortunately, there are several speed-ups and optimizations that can be applied to most SpamAssassin installations to speed up its rule processing, especially on Debian and Ubuntu GNU/Linux-based systems. These instructions can be adopted to other operating systems as well.</p>
<p>This article does not discuss configuring your mail filtering system (i.e. procmail, maildrop). This depends completely on your setup, and more than likely there are plenty of other articles that describe the best way to setup what you want.
<!--break--></p>
<h3>The spamc/spamd client/server combination</h3>
<p>A normal SpamAssassin setup invokes the <code>spamassassin</code> command for each incoming e-mail that needs to be scanned. This process is expensive when you consider what this does: for each incoming e-mail, a perl interpreter starts and loads all of SpamAssassin's perl code, including its thousands of rules. Starting SpamAssassin like this, with a decent amount of incoming e-mail, will increase I/O load and slows things down, fast.</p>
<p>SpamAssassin 2.x introduced the <a href="http://spamassassin.apache.org/full/3.0.x/dist/doc/spamc.html">spamc</a>/<a href="http://spamassassin.apache.org/full/3.0.x/dist/doc/spamd.html">spamd</a> combination to alleviate this issue. <code>spamd</code> is a version of SpamAssassin intended to be run as long-running process that accepts connections from <code>spamc</code>. <code>spamc</code> is a lightweight C program made to replace the <code>spamassassin</code> command, taking a message and passing it to <code>spamd</code> for processing. This alleviates all of the I/O caused by loading perl and all of SpamAssassin's rules repeatedly. Instead, both perl and SpamAssassin's rule sets are only loaded once.</p>
<p>Setting this up and relatively quick and easy. Install:</p>
<pre><kbd>sudo aptitude install spamc
</kbd></pre>
<p>Then, edit /etc/default/spamassassin to enable startup of the spamd process. In this file, change:</p>
<pre><samp>ENABLED=1
</samp></pre>
<p>Start the spamd process:</p>
<pre><kbd>sudo /etc/init.d/spamassassin start
</kbd></pre>
<p>Next, in your mail filtering scripts wherever you invoke the <code>spamassassin</code> command, invoke the <code>spamc</code> command instead. After verifying spam filtering still works after all these changes, you are done.</p>
<p>One important thing to note: the spamd/spamc combination sets up another service running on your system, possibly opening up a security hole waiting to be exploited. Make sure to follow due process (securing user accounts, setting up firewall, etc) before enabling new network services.</p>
<h3>Precompiled Rules</h3>
<p>Erich Schubert went into <a href="http://blog.drinsama.de/erich/en/linux/2007122403-spamassassin-precompiled-rules.html">SpamAssassin 3.2's ability to precompile rules</a> a few months ago. While Perl's regular expressions are fast, C regular expressions can be faster (and consume less memory). SpamAssassin can compile its rules into a C shared library that is used instead of interpreted perl code. Eric mentions a negative to precompilation: it requires your mail server to have a C compiler.</p>
<p>If you're comfortable with that, setting up your system for precompiling SpamAssassin's rules is easy. Install the required depencencies:</p>
<pre><kbd>sudo aptitude install re2c build-essential
</kbd></pre>
<p>and run the <a href="http://spamassassin.apache.org/full/3.2.x/doc/sa-compile.html">sa-compile</a> command:</p>
<pre><kbd>sudo sa-compile
</kbd></pre>
<p>You then need to configure SpamAssassin to use the precompiled rules. This is done by editing /etc/spamassassin/v320.pre, and uncommenting out the line:</p>
<pre><samp>loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
</samp></pre></div>